Changing default sample rate to 44100 caused a regression for Yeti Nano microphone
- PipeWire version (
pipewire --version
): 0.3.60 - Distribution and distribution version (
PRETTY_NAME
from/etc/os-release
): Fedora Linux 37 - Desktop Environment: GNOME
- Kernel version (
uname -r
): 6.0.9-300.fc37.x86_64
Description of Problem:
The fix for issue #2718, which changes the default probing sample rate from 48000 to 44100 had an unintended consequence. On a Yeti Nano microphone when the sample rate of the output (a headphone port for zero-latency listening and I guess general sound output) doesn't match the input sample rate the LED will blink orange. If you actually used this port for audio output then you won't be able to hear anything. Assuming the sample rate wasn't corrected on first use. I use Bluetooth headphones so I don't actually use this feature. Although, the blinking orange LED showing a sample rate mismatch appears as soon as you start to record something, for example in a video conference session. This is because the output was set to a sample rate of 44100 rather than 48000 by the the previously mentioned change. I rebuilt the pipewire-0.3.60-5.fc37.x86_64
package and dropped only the related patch and that resolved the issue, which confirmed it was a recent update that caused it and it was due to this sample rate patch. I see this change is now in master
branch as well. I tried some wireplumber changes to workaround this (as mentioned in that issue), but I guess they don't do anything because I need to open the device for those changes to apply. When I do open the device the issue is resolved even without any wireplumber changes because I think it defaults to 48000 like the input does.
I discovered while debugging that I can "fix" the issue by using the command: arecord -q -D sysdefault:CARD=Nano -s 1 -f S24_3LE | aplay -q -D sysdefault:CARD=Nano
. As you probably know better than me this basically opens the device for a very short time (1 sample) which causes the sample rate to change to the default 48000. I wonder if we need the probing sample rate to be an option since I read the related fix resolved a problem with another microphone and reverting the change would reintroduce the regression. Or, maybe you have some other suggestions on how to resolve this.
Steps to Reproduce:
- Switch the microphone to "Analog Stereo Input" only
- Reboot or whatever is needed to restart the audio session
- Open up
pavucontrol
which will open the input now, but not the output
Actual Results:
The input sample rate mismatches the output sample rate leading to a blinking orange LED.
Expected Results:
The default sample rate 48000 should be applied to both the input and output device.