Bug 202097 - Realtek analog audio output limited to 48 kHz, chips support up to 192kHz
Summary: Realtek analog audio output limited to 48 kHz, chips support up to 192kHz
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-30 15:53 UTC by Mark
Modified: 2023-05-25 12:30 UTC (History)
4 users (show)

See Also:
Kernel Version: 5.13.1
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Output from the ALSA info debug script (41.85 KB, text/plain)
2018-12-30 15:53 UTC, Mark
Details
output of alsa-info.sh for Sony Vaio Fit ALC233 (31.24 KB, text/plain)
2021-04-09 05:00 UTC, Geraldo Nascimento
Details
Output of cat /proc/asound/card0/codec#0 (142.66 KB, image/png)
2021-07-03 11:11 UTC, Mark
Details
Output of cat /proc/asound/card0/codec#0 (10.16 KB, text/plain)
2021-07-04 00:50 UTC, Geraldo Nascimento
Details
Output from /proc/asound/card0/codec#0, after power off restart (9.52 KB, text/plain)
2023-05-08 15:54 UTC, haro41
Details
Output from /proc/asound/card0/codec#0, after windows driver running and reboot (warm start) (9.55 KB, text/plain)
2023-05-08 15:55 UTC, haro41
Details

Description Mark 2018-12-30 15:53:48 UTC
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.
Comment 1 Mark 2018-12-30 15:55:18 UTC
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.
Comment 2 Jaroslav Kysela 2018-12-30 16:53:26 UTC
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
Comment 3 Mark 2018-12-30 17:15:51 UTC
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).
Comment 4 Takashi Iwai 2019-01-01 09:18:26 UTC
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.
Comment 5 Mark 2019-05-27 20:57:23 UTC
(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.
Comment 6 Mark 2019-06-10 13:38:19 UTC
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.
Comment 7 Christo Grozev 2020-03-17 08:38:07 UTC
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
Comment 8 Mark 2020-03-18 14:00:44 UTC
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
Comment 9 Mark 2020-05-19 07:09:15 UTC
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.
Comment 10 Geraldo Nascimento 2021-04-09 05:00:20 UTC
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.
Comment 11 Mark 2021-07-03 11:09:36 UTC
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
Comment 12 Mark 2021-07-03 11:11:25 UTC
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
Comment 13 Geraldo Nascimento 2021-07-04 00:47:40 UTC
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.
Comment 14 Geraldo Nascimento 2021-07-04 00:50:17 UTC
Created attachment 297701 [details]
Output of cat /proc/asound/card0/codec#0

Here's cat /proc/asound/card0/codec#0 on my machine.
Comment 15 Geraldo Nascimento 2021-07-08 03:07:19 UTC
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.
Comment 16 Mark 2021-07-09 23:16:41 UTC
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.
Comment 17 Geraldo Nascimento 2021-07-12 18:24:02 UTC
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?
Comment 18 Mark 2021-07-13 13:10:46 UTC
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.
Comment 19 Mark 2021-07-13 13:13:20 UTC
(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...
Comment 20 Geraldo Nascimento 2021-07-13 22:39:27 UTC
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.
Comment 22 haro41 2023-05-08 15:54:52 UTC
Created attachment 304228 [details]
Output from /proc/asound/card0/codec#0, after power off restart
Comment 23 haro41 2023-05-08 15:55:52 UTC
Created attachment 304229 [details]
Output from /proc/asound/card0/codec#0, after windows driver running and reboot (warm start)
Comment 24 haro41 2023-05-08 16:00:45 UTC
I can confirm this bug (see attachments). This is on ALC3234 (Dell Optiplex 3040 micro).
Apparently, the initialisation by windows drivers makes a difference.
Comment 25 haro41 2023-05-25 12:30:25 UTC
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

Note You need to log in before you can comment on or make changes to this bug.