Created attachment 303568 [details] lsusb -v -d 0a12:1004 On my second PC, I'm using a USB audio device called "Avantree Leaf" to pass audio via bluetooth to a receiver. About 1-2 months ago, I noticed that I have no audio with this device when playing sounds via wine applications (e.g. foobar2000 or any kind of game via proton/wine), neither via the pulseaudio output, nor alsa. Native Linux applications work fine (or at least I haven't found one yet that doesn't work) via both pulse or alsa output. If I select another audio device (e.g. the speakers of the screen via HDMI) in winecfg for the respective wine prefix, then the audio does work. Also, if I "prime" the device by playing audio via a native application and then the audio works. I'm using pipewire-0.3.63 with pipewire-pulse as an audio server, but I've also tried with recent pulseaudio and they are both affected. For pipewire, I played a bit with the settings and found: Brings back audio: clock.min-quantum 512 (lower values don't work) Doesn't change the outcome: ["api.alsa.period-size"] = 16 up to 1024 ["api.alsa.disable-batch"] = true/false (in combination with the above) ["api.alsa.headroom"] = 64 up to 1024 The output I get from `cat /proc/asound/Leaf/pcm0p/sub0/hw_params`: Native application: access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 256 buffer_size: 32768 foobar2000 via wine: access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 128 buffer_size: 32768 So they are the same, except for the period_size. Yesterday, I finally made some effort to track this down and I had to go back all the way to v5.14 to find the commit that is responsible: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.2-rc3&id=307cc9baac5c07b23da78d75c3d4755e9cffab26 If I test the revision before that commit, everything works as expected. If I test this revision, then the audio fails. Of course with such an old commit, I'm not 100% sure that this is the only thing, as I can't simply revert it on a newer kernel. Too much change happened in sound/usb since then. I did however test every mainline kernel version since 5.10 and the behavior was consistent. Please let me know if you need any further information.
You can pass lowlatency=0 module option to snd-usb-audio driver for the safe effect as reverting the changes. But, please make sure that the problem still persists with the latest sound.git tree for-linus branch. There have been a few fixes for USB-audio, and if the change above is still relevant, we need to verify whether you're hitting the issue that has been already addressed or not. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git If the latest for-linus branch still doesn't work, please give alsa-info.sh output. Run the script with --no-upload option.
Created attachment 303577 [details] Output of alsa-info.sh
(In reply to Takashi Iwai from comment #1) > You can pass lowlatency=0 module option to snd-usb-audio driver for the safe > effect as reverting the changes. > First thanks for looking at this. It's been bugging me for quite a while now. Also thanks for the hint. Adding the module option lowlatency=0 indeed changes the behavior, in that case I do get audio from foobar2000 without further changes to the setup. > But, please make sure that the problem still persists with the latest > sound.git tree for-linus branch. There have been a few fixes for USB-audio, > and if the change above is still relevant, we need to verify whether you're > hitting the issue that has been already addressed or not. > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > Yes, it's still present in that version, just tested it. > If the latest for-linus branch still doesn't work, please give alsa-info.sh > output. Run the script with --no-upload option. Attached the output of the script.
Thanks. So the period size differs when you play from wine or from another application even though both of them output via pipewire? That's interesting. Is the wine really output via pipewire?
Yes, via pipewire-pulse. In winecfg, I selected pulseaudio. I can see the stream in pipewire. But as I said, the same happens if I install pulseaudio instead of pipewire-pulse and disable pipewire completely. Also, it blocks the device, because if I then try to play something with e.g. mpv. I forgot to mention, that pipewire will log an error message: pipewire[1836]: spa.alsa: front:0: (12 missed) snd_pcm_avail after recover: Broken pipe
Also see this bug report: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2739
The EPIPE error means usually PCM buffer xrun, so that's probably timing-related things. The lowlatency mode allows to start stream at the exact timing, while the non-latency mode delays the start. Could you check whether aplay (with -Dplughw:Leaf) with the explicit --buffer-size and --period-size option that matches with both the working and the non-working cases? Disable pipewire beforehand (e.g. systemctl --user stop wireplumber) at testing it. This may clarify whether it's a device issue with the certain setup, or it's rather dependent on the behavior of application.
If I pass only --period-size it works fine (tested values ranging from 16 to 1024). (Actually the sound is pitched up for low values, don't know if that is expected.) If I specify both, it can happen with some combinations that I get a buffer underrun, e.g.: aplay -Dplughw:Leaf --period-size=200 --buffer-size=500 message.wav underrun!!! (at least 0.024 ms long) The message is repeated numerous times. With --buffer-size=400 or --buffer-size=600, it works, though. For message.wav, it has to do a sample rate conversion. Don't know if that could be problematic. That was just a random wave file I found on my PC.
Created attachment 303588 [details] Output of aplay -v -Dplughw:Leaf --period-size=200 --buffer-size=500 message.wav
Takashi, just wondering: did this regression report fall through the cracks? Or are you waiting for any more data from the reporter?
Well, that's likely a side-effect of the improved data handling; now with the lower latency, the data is processed in a faster way, while the application didn't expect / handle it properly. (The test with --period-size=200 --buffer-size=500 would need a RT priority, otherwise the process won't be woken up properly. And, pipewire uses with a much higher value, and this is possibly a different scenario.) That said, it's suspected more as an application bug that casually surfaced by the improvement in the kernel side. And, for making the kernel slower, you have the workaround (lowlatency=0 option).
Hm, just to be sure, by application do you mean pipewire or the application that initiated the sound stream? (So wine, in my case.)
I guess wine as the primary target. But if the problem happens over pipewire, pipewire must be more or less responsible, too. In the older versions, it just worked because there was a hidden latency in the USB audio driver side, I guess.
Ok, I'll contact them, then. Thanks for looking into this.