Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audio on Arch Linux #56

Closed
joeknock90 opened this issue Mar 23, 2023 · 14 comments
Closed

Audio on Arch Linux #56

joeknock90 opened this issue Mar 23, 2023 · 14 comments

Comments

@joeknock90
Copy link

Seems I can't get audio working on Arch working through the instructions on the README.

uname -a
Linux pixbook.example.com 6.2.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 18 Mar 2023 01:06:36 +0000 x86_64 GNU/Linux

Attached is dmesg:

dmesg.log

@jmontleon
Copy link
Owner

OK, we have the same kernel and same MrChromebox firmware so that's a good start. There are others who have posted here that have Arch successfully working so we should be able to get it working.

That said your dmesg output looks very sparse when it comes to the audio.

Searching on your odd rt5514 error, this explanation looks interesting to say the least.

https://github.com/torvalds/linux/blob/master/sound/soc/codecs/rt5514.c#L1289-L1303

	/*
	 * The rt5514 can get confused if the i2c lines glitch together, as
	 * can happen at bootup as regulators are turned off and on.  If it's
	 * in this glitched state the first i2c read will fail, so we'll give
	 * it one change to retry.
	 */
	ret = regmap_read(rt5514->regmap, RT5514_VENDOR_ID2, &val);
	if (ret || val != RT5514_DEVICE_ID)
		ret = regmap_read(rt5514->regmap, RT5514_VENDOR_ID2, &val);
	if (ret || val != RT5514_DEVICE_ID) {
		dev_err(&i2c->dev,
			"Device with ID register %x is not rt5514\n", val);
		return -ENODEV;
	}

Can you try shutting down and hotting Power+Refresh (circular arrow third from the left, top row of the keyboard) to boot and see if it clears anything. I know of at least one other glitch (left port stops charging or only slow charging) by doing this. I wonder if it could clear your problem as well.

If not, can you provide the output from lsmod, aplay -l, ls /etc/modprobe.d and I guess we'll go from there.

@jmontleon
Copy link
Owner

Are you using a stock power supply? Do you have any peripherals plugged in when booting?

I'll admit I don't understand the I2C glitch issue. I'm wondering if some external factor could be triggering it...

@joeknock90
Copy link
Author

Thanks for your help as always. Nice find. interesting workaround.

Unfortunately hard reboot didn't seem to have an affect.

I don't even think I have the original power supply for this thing, but the problem seems to persist even when just on battery, if that matters. No peripherals plugged in.

aplay -l
aplay: device_list:274: no soundcards found...

No files in /etc/modprobe.d/

lsmod's output attached.
lsmod.txt

@jmontleon
Copy link
Owner

I think if -ENODEV is being returned there's probably little hope of the device working.

If it's happening even when everything is unplugged including power, it probably eliminates anything external as a source of the problem.

Audio worked when you had ChromeOS installed I'm assuming?

You're booting via UEFI and not legacy?
https://mrchromebox.tech/#bootmodes

I don't know that legacy can't work but @saxa has a lot of problems and he's using legacy. I wonder if he sees a similar rt5514 error in dmesg.

I wonder if MrChromebox might have an idea over on https://github.com/MrChromebox/firmware

I definitely have more questions than answers...

@joeknock90
Copy link
Author

It was indeed working on chromeOS, and also previously worked on some 5 kernel. 5.15 I think?

I am indeed using UEFI.

Maybe I'll restore chromeOS and make sure that I can get audio. Been a while since I had it on here.

Should I open a similar issue with mrchromebox?

@saxa
Copy link

saxa commented Mar 24, 2023

@jmontleon yup, I am using the legacy bios, but to be honest except the sound not working on my fedora install there is no other problems. Slackware install works ok everything. I just see pulseaudio makeing noise in dmesg , but will investigate more and report when I have some more time.

@jmontleon
Copy link
Owner

jmontleon commented Mar 24, 2023

@joeknock90 I think it wouldn't hurt to check with MrChromebox if you confirm audio is still working with ChromeOS and then flash back to Coreboot and the issue persists, if you're willing to go through those steps to troubleshoot.

I would definitely keep this open and would be interested in anything learned from your testing ChromeOS and talking to MrChromebox.

I can dig around the coreboot and mrchromebox repos a bit and see if there's anything that might be relevant

Some other thoughts:
Another thing that may be worth trying, since you mentioned 5.15 working... I was recentlly working at the other open issue for HDMI audio and it was mentioned Linux Mint 21.1 still has working HDMI. We found that that was because it is still using 5.15 and HDMI broke at 5.17. Which is to say, if you want to compare how an older kernel behaves you could try installing Mint 21.1.

That code that's printing the error has been in the kernel for 6-8 years, so it's nothing new, not to say something outside the block couldn't have changed along the way that's affecting it. It could come down to someone affected needing to do a bisect to track down the offending commit if older kernels are working and new are not.

I also thought maybe the firmware files from the chrome recovery image might be old/new/different, but I don't think we're even getting to loading anything yet on your system so that's probably not likely.

@ntcarlson
Copy link

Hello. I have audio mostly working on my Pixelbook under Arch. First thing I will note is that I could not get audio working with Pipewire, but it works fine with Pulseaudio.

In case it is helpful for you to compare against, here is some information from my system.

  • I am booting with UEFI using firmware version MrChromebox-4.18.2 11/29/2022 (which looks to be older than what you are using).

  • dmesg output: dmesg.txt (No rt5514 related errors)

  • lsmod output: lsmod.txt

  • SHA256 hashes of manually installed audio files (firmware files pulled from version 15117.112 recovery image):

8af231c82151d7edfa6083293845a62d3adb9423a81a853051179d861f8b1cdd  /lib/firmware/intel/dsp_fw_C75061F3-F2B2-4DCC-8F9F-82ABB4131E66.bin
7f1138d21c13703df966a7ceaa4450b84420963e69501560b4f785713c1f489a  /lib/firmware/9d71-GOOGLE-EVEMAX-0-tplg.bin
c6a75eb1245899c81669e22de5169b6a779d108e12f0d36389974fdd28eff886  /lib/firmware/dsp_lib_dsm_core_spt_release.bin
dea1006da11192cabfea821e806393b0e37630207059b4ea53faec27fd429220  /opt/google/dsm/dsmparam.bin
89604b6d9b17cf101da572e389986d94cf18ec215cc6030d4ae80c378d5b8eef  /usr/share/alsa/ucm2/Intel/kbl-r5514-5663-/HiFi.conf
83991f57452865f704fce608843f3ed816160e96edcdaba4e71d83fb0040f88f  /usr/share/alsa/ucm2/Intel/kbl-r5514-5663-/kbl-r5514-5663-.conf
89604b6d9b17cf101da572e389986d94cf18ec215cc6030d4ae80c378d5b8eef  /usr/share/alsa/ucm2/conf.d/kbl-r5514-5663-/HiFi.conf
83991f57452865f704fce608843f3ed816160e96edcdaba4e71d83fb0040f88f  /usr/share/alsa/ucm2/conf.d/kbl-r5514-5663-/kbl-r5514-5663-.conf
  • Audio related packages installed:
pacman -Q | grep -P '(alsa|pulse|pipewire)'

alsa-lib 1.2.8-1
alsa-plugins 1:1.2.7.1-2
alsa-topology-conf 1.2.5.1-3
alsa-ucm-conf 1.2.8-1
alsa-utils 1.2.8-1
libpipewire 1:0.3.67-1
libpulse 16.1-6
pulseaudio 16.1-6
pulseaudio-alsa 1:1.2.7.1-2
  • aplay -l output:
**** List of PLAYBACK Hardware Devices ****
card 0: kblr55145663max [kbl-r5514-5663-max], device 0: Audio (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: kblr55145663max [kbl-r5514-5663-max], device 2: Headset Audio (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: kblr55145663max [kbl-r5514-5663-max], device 6: Hdmi1 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: kblr55145663max [kbl-r5514-5663-max], device 7: Hdmi2 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Let me know if I can provide anything else that might be useful in diagnosing your audio issue.

@jmontleon
Copy link
Owner

@ntcarlson thanks for confirming. Pipewire is the same story on Fedora. As far as I can tell it's gotten worse rather than better. The mic used to record noise but output worked. Last time I tried output was just static as well. I filed an issue against pipewire for the mic but it never went anywhere.

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1452

It probably wouldn't be a bad idea for someone to file a new bug for output. Maybe the fix for one will resolve both...

@joeknock90
Copy link
Author

So today I did 2 things.

Installed 5.15.77 on arch linux via the arch build system. Audio still did not working.

I did a full chromeos recovery to be sure, and sure enough, audio IS working.

Not sure where to go from here honestly.

@jmontleon
Copy link
Owner

My advise, if you want to try to solve it, is try re-flashing the latest MrChomebox firmware, install your distro of choice (Arch should be fine if that's what you're aiming for, others have it working so no reason it should be any better/worse than any other), and if the issue persists file an issue on the firmware repo and see if he has any thoughts.

It may be it has little or nothing to do with coreboot. If he hasn't any idea perhaps an email to alsa-devel at alsa-project.org. Several people there with much more of a clue than I might be able to explain what's happening here and how you might remedy it if at all.

The larger comment on the patch that added the comment makes me think there is a hardware issue here that they're trying to work around that for some reason your laptop isn't responding to.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.3-rc3&id=7952b4baff402

ASoC: rt5514: Unconfuse the rt5514 at probe / resume time
The rt5514 can get confused and incorrectly detect a start bit if the
SCL/SDA lines happen to both go low and then high again.  This
situation has been seen to happen at reboot time and is also
theoretically possible during suspend/resume if the rt5514 keeps power
but we shut down the i2c connection.

When this happens the rt5514 is confused about the state of the i2c
bus and won't recognize its own address.  That will lead to the rt5514
incorrectly NAKing the first transfer.

A single i2c transfer to any address should be enough to get the
rt5514 out of this funky state.

It is currently believed that this problem should be fixed in the
rt5514 driver itself because it seems that the i2c controller in the
rt5514 is easily confused.  Most i2c devices wouldn't detect a start
bit in this case.

The only thing I will say regarding any one distro over another: if you reach out someone returns a kernel patch your way to try and you're uncomfortable with building and installing custom kernels it would be far easier for me lend a hand building a patched kernel package for Fedora than another distro. If you're comfortable with that in another distro then I see no issue with one over another.

I'd urge patience and determination if you want it fixed. For issues I can reproduce that I've gone down the road of fixing it's generally takes a day to three running git bisects, and then weeks of fiddling with drivers trying to understand and submit a patch. I'm generally very over my head digging in kernel drivers, but I've managed a few times. It will unfortunately be difficult for me to drive an issue I cannot reproduce. But there are a lot of smart folks working on this stuff. My best advice is be concise and polite when reaching out and explaining the error and hopefully the right person sees it and can help.

You can feel free to link anything you learn here. It's not impossible someone else will see the same problem and value the information.

@joeknock90
Copy link
Author

After reinstalling ChromeOS, re-running MrChromebox's firmware util, reinstalling Arch Linux, and re-doing the audio setup steps, I now have working audio!

image

This must have been some sort of strange firmware issue.

If it matters, originally when setting this device up, I had used MrChromebox's firmware util, and since had used it again in Arch to update the firmware.

@jmontleon Your knowledge, patience, and commitment helping is astounding, and I can't express enough how much it is appreciated. I am a Red Hat administrator for a government agency by trade, and you guys are always phenomenal to work with.

If there's anything further I can provide please let me know.

@jmontleon
Copy link
Owner

Hah, that's awesome that that worked, but I can only guess what happened here.

If you haven't had ChromeOS on there in a really long time then perhaps it updated an out of date and problematic firmware somewhere in the background or perhaps something did not go well when flashing an older coreboot release that the more recent and newer version handled better.

Whatever the cause, I'll add a note to the troubleshooting section with the error and a link to this issue so if others ever see this perhaps they can follow the same steps to get unblocked.

@jmontleon
Copy link
Owner

dcc5de0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants