Created attachment 280195 [details] Output from the ALSA info debug script There seems to be an issue with the onboard laptop audio chip Realtek ALC233. Namely, I've noticed that I cannot make use of all the sampling rates that the chip supports in GNU/Linux. The chip supports up to 24-bit/192kHz analog stereo output, but in the three Linux distributions I've tried (Ubuntu, Fedora, Manjaro) I can only get either 44.1 or 48 kHz. The problem manifests itself by throwing the following error when attempting to play, for example, a 96kHz file in Audacious: "ALSA error: snd_pcm_hw_params_set_rate failed: Invalid argument." If I attempt to play such a file using PulseAudio, I am able to play the file, but it gets resampled to 48kHz (which I've verified by running "cat /proc/asound/card0/pcm0p/sub0/hw_params") In Windows, I can get up to 192kHz without problems. I've attached the output from the ALSA info script.
Oh yes, by the way, i have tried using different kernel versions (4.18, 4.19, 4.20, 4.21) and the issue persists in all cases.
I do not think that this chip supports 192khz for the analog output. The codec parameters from the alsa info output (those parameters are read from the codec): Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x44 0x44] Converter: stream=1, channel=0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="ALC233 Analog", type="Audio", device=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x00 0x00] Converter: stream=1, channel=0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0
Well maybe it's driver/codec bug then, because, as I said, I can get 192kHz output in Windows no problem (using WASAPI Exclusive mode, meaning direct access to hardware).
Possibly you are fooled by the marketing. Judging from the alsa-info.sh output, this codec chip actually supports 192kHz, but only for the specific I/Os. Namely, for the analog output pins, it supports only up to 48k, while it can work up to 192k for the digital output. Maybe Windows driver doesn't switch this dynamically but accepts the highest rate at the entry point, while it ends up with the lower 48k output in practice.
(In reply to Takashi Iwai from comment #4) > Possibly you are fooled by the marketing. Judging from the alsa-info.sh > output, this codec chip actually supports 192kHz, but only for the specific > I/Os. > Namely, for the analog output pins, it supports only up to 48k, while it can > work up to 192k for the digital output. > > Maybe Windows driver doesn't switch this dynamically but accepts the highest > rate at the entry point, while it ends up with the lower 48k output in > practice. I apologize upfront for reviving this thread, but I have some relevant news to share on this topic. So over the weekend I did a clean install of Ubuntu 19.04. And, among other things, I checked to see if this issue still existed. And for the first two days after doing the fresh install of Ubuntu 19.04, I could get ALSA to output 24/96 and 24/192 audio directly to hardware and the playback worked perfectly! Also, checking the output of "cat /proc/asound/card0/pcm0p/sub0/hw_params", I could see the sampling rates of 96000 and 192000 under "Speaker Playback Volume" and "Headphone Playback Volume"! Which seems to confirm my claim that the audio chip in question, Realtek ALC233, does indeed support those sampling rates natively. However, in a turn of events, as I was trying to play a 24/96 audio file just this evening, I was disappointed to see that the playback failed and now those sampling rates higher than 48000 Hz are again not getting recognized by Linux (and thus also not listed by the "cat" command). So the situation is now again the same as it was when I originally posted the issue.
Another update, or to be precise, correction. It seems that everything works as it should (full range of sampling rates, up to 192kHz, are detected on all audio outputs, including analog) up until the first time computer is shut down. In other words, even after installing all the updates and restarting the computer (many times), it works. But, as soon as the computer is shut down for the first time (following a clean install of the system) and then booted again, from that point on Linux only detects sampling rates up to 48kHz. Strange.
Hi Mark. I stumbled into exactly the same problem, albeit with an ALC255 chip (which under Windows indeed does play back at 192khz). Unfortunately I cannot reproduce your temporary solution - i.e. even after I installed Ubuntu 19.10, I get the same limitation. Did you by chance do a alsa-info dump under the "still-working" scenario? It owuld be useful to see what it shows. Best regards Christo
Hi Christo, Unfortunately, the the temporary solution you mention I found was never even a solution. The issue appears when the computer is first shut down following installation of the OS and from that point on, it is always present. I do not have a alsa-info dump file from that short period of time when the issue was not present, but looking at the dump attached to this thread (where the issue is present), I can tell you that in the section: Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Speaker Playback Volume", index=0, device=0 (...) PCM: rates [0x60]: 44100 48000 I could additionally see the rates of 96000 and 192000. Same goes for: Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0
Just to confirm again: the issue still appears on fresh installs of Ubuntu 20.04 and Pop OS 20.04. The key is that the issue first appears when the PC is first powered off (following the installation of a distro). Before the first shutdown, I can see all the supported sampling rates, including 96000 and 192000 for both "Speaker Playback Volume" and "Headphone Playback Volume". After the first shutdown, they never appear again.
Created attachment 296309 [details] output of alsa-info.sh for Sony Vaio Fit ALC233 Mark, on Gentoo Linux running latest 5.12-rc6 this bug is not reproducible. Thank God, or it would disrupt my audio workflow a lot. You see, it is a funny situation because I usually do not shut down my notebook, I always reboot then shut down through reFind GUI. Anyway for a test I shut down my computer twice, first via XFCE GUI which is polkit based I believed and then through shutdown -P now. Nothing, nada. Can play 96000Hz files. Starts JACK on 192kHz. A dream come true. Now that's not to say that I don't have a vague memory that 48000Hz once was the limit for me, too. But I can't reproduce your bug, thank God almighty.
Geraldo, on a fresh install of Pop OS 21.04, the issue is still there. See the screenshot attached to this bug, or at this link: https://ibb.co/sW4yBd1
Created attachment 297693 [details] Output of cat /proc/asound/card0/codec#0 Output of cat /proc/asound/card0/codec#0, proving that the bug/issue (still) exists. This screenshot was made on a fresh install of Pop OS 21.04
Hi Mark, I believe you when you say the bug still exists, I was just pointing out that since it's not reproducible consistently across distributions (I'm running gentoo Linux) it may not be a kernel bug per se.
Created attachment 297701 [details] Output of cat /proc/asound/card0/codec#0 Here's cat /proc/asound/card0/codec#0 on my machine.
Mark, I must also emphasize that I'm running mainline kernels, and trying to keep up with their development. To establish the base of your bug as kernel-related you must boot a mainline kernel, period. And then, to be honest, you must a lot of times disable PulseAudio, PipeWire and other sound-services to make sure the bug really is in ALSA.
Hello Geraldo, I tried installing the latest mainline kernel, version 5.13.1 (5.13.1-051301-generic), and the situation is still exactly the same.
Hi, Mark, I know it can be frustrating sometimes to track bugs. At least you got the latest development kernel in the process, even if didn't solve your bug. My bet is that you will track the bug somewhere around to PulseAudio fiddling with ALSA. When installing Pop!_OS 21.04 did you get the same behavior as you reported earlier, that 192Khz initially worked even after reboots, and then it suddenly stops working after shutdown?
Hi Geraldo, Yes, 96 and 192 kHz both work perfectly right after the installation of any distro that I have tried. That initial shutdown makes a difference and messes things up for some reason.
(In reply to Mark from comment #18) > Hi Geraldo, > > Yes, 96 and 192 kHz both work perfectly right after the installation of any > distro that I have tried. That initial shutdown makes a difference and > messes things up for some reason. Also another possible cause, just thinking out loud, could be something related to BIOS and the detection of device capabilities, i.e. the scripts/procedures that run when booting from the shutdown state...
Hi, Mark, Let's genuinely pray this is not BIOS/firmware related, because some vendors have the bad habit of not releasing fixes properly, and the BIOS/firmware is always a binary blob. Even if you could reverse engineer the firmware with Ghidra or IDA Pro it would be risky to perform a write with modifications, without having handy a Flash Eprom (EEPROM) Programmer AKA BIOS writer. So let's please scratch that as an option for what to do to track this annoying bug. I think this symptom you reported, that it initially works in 96KHz and 192KHz even across reboots before performing the first shutdown, will be the key to track the bug. Also, worse than PulseAudio fiddling with ALSA is systemd fiddling with ALSA. When you got some time, please try a distribution that does not include systemd (or PulseAudio) but uses a traditional init system and see if the bug is still there. That'd be my suggestion. Once you find a distribution where you cannot replicate the bug, where 192KHz just works and works and works, like my gentoo setup here, then you can begin exploring what shutdown "script" is causing the nasty symptom so you can submit a fix downstream for e.g., Canonical's Ubuntu.
You may try to send a question to Realtek developers: https://github.com/torvalds/linux/commits?author=kailangyang https://github.com/torvalds/linux/commits/master/sound/pci/hda/patch_realtek.c
Created attachment 304228 [details] Output from /proc/asound/card0/codec#0, after power off restart
Created attachment 304229 [details] Output from /proc/asound/card0/codec#0, after windows driver running and reboot (warm start)
I can confirm this bug (see attachments). This is on ALC3234 (Dell Optiplex 3040 micro). Apparently, the initialisation by windows drivers makes a difference.
A possible fix for this problem: 1. compare the codec coefs with and without a previous windows boot 2. adapting the coefs via 'hda_verb' tool, accordingly. See: https://bugzilla.kernel.org/show_bug.cgi?id=195303#c5 https://bugzilla.kernel.org/show_bug.cgi?id=195303#c305