Description of problem: Pulseaudio always resamples highres audio to the sample rate specified by default-sample-rate, despite "avoid-resampling = true". Audio that matches alternate-sample-rate is resampled in the same way. Version-Release number of selected component (if applicable): pulseaudio-libs-14.0-2.fc33.x86_64 pulseaudio-14.0-2.fc33.x86_64 pulseaudio-libs-glib2-14.0-2.fc33.x86_64 pulseaudio-utils-14.0-2.fc33.x86_64 pulseaudio-module-x11-14.0-2.fc33.x86_64 xfce4-pulseaudio-plugin-0.4.3-4.fc33.x86_64 alsa-plugins-pulseaudio-1.2.2-4.fc33.x86_64 pulseaudio-module-bluetooth-14.0-2.fc33.x86_64 How reproducible: Steps to Reproduce: 1. Set "avoid-resampling = true" in daemon.conf 2. Set default-sample-rate = 44100 in daemon.conf 3. Set alternate-sample-rate 96000 in daemon.conf 4. Restart pulseaudio 5. Play a 96000 audio file Actual results: File is played as 44100 audio. Pacmd list-sink-inputs shows that resampling is happening. Expected results: Audio file plays at 96000. Additional info: This worked flawlessly with Fedora 32. The DAC/amplifier is a Fostex HP-A4. When I set default-sample-rate = 96000, the same is happening as described. All audio files are resampled to 960000.
After a lot of searching, I found out that downgrading to kernel 5.10.17 (and other kernels from the 5.10.xx series) resolves the problem immediately. Unfortunately, I could not figure out where the problem lies. Something in ALSA that changed? Pulseaudio that is not ready for 5.11 yet? Don't know where to look further. FWIW: updated to kernel 5.11 on another machine, and encountered the same problem as described here. Dowongrading to 5.10.17 resolved it.
After two days of bisecting the offending patch, I finally had to give up. Unfortunately, there is a patch in between -rc3 and -rc4 that crashes my machine. This makes me unable to classify a kernel as good or bad. The only thing I can see so far is that the above mentioned behaviour is a kernel problem, and that all 5.10.xx kernels and 5.11-rc1 are fine. If anybody has an idea how to find the problematic commit, I am more than willing to help. 5.11.1 does not resolve the bug either.
Finally, I managed to bisect the offending commit. Reverting it on top of kernel 5.11 / 5.11.1 resolves the problem. [root@chiara linux-stable]# git bisect good e4ea77f8e53f9accb9371fba34c189d0447ecce0 is the first bad commit commit e4ea77f8e53f9accb9371fba34c189d0447ecce0 Author: Takashi Iwai <tiwai> Date: Mon Jan 11 09:16:11 2021 +0100 ALSA: usb-audio: Always apply the hw constraints for implicit fb sync Since the commit 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for implicit fb sync"), we apply the hw constraints for the implicit feedback sync to make the secondary open aligned with the already opened stream setup. This change assumed that the secondary open is performed after the first stream has been already set up, and adds the hw constraints to sync with the first stream's parameters only when the EP setup for the first stream was confirmed at the open time. However, most of applications handling the full-duplex operations do open both playback and capture streams at first, then set up both streams. This results in skipping the additional hw constraints since the counter-part stream hasn't been set up yet at the open of the second stream, and it eventually leads to "incompatible EP" error in the end. This patch corrects the behavior by always applying the hw constraints for the implicit fb sync. The hw constraint rules are defined so that they check the sync EP dynamically at each invocation, instead. This covers the concurrent stream setups better and lets the hw refine calls resolving to the right configuration. Also this patch corrects a minor error that has existed in the debug print that isn't built as default. Fixes: 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for implicit fb sync") Link: https://lore.kernel.org/r/20210111081611.12790-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai> sound/usb/pcm.c | 171 +++++++++++++++++++++++++++++++++++--------------------- 1 file changed, 108 insertions(+), 63 deletions(-) [root@chiara linux-stable]#
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.