Bug 216909
| Summary: | Avantree Leaf USB audio device does not play sound in applications run via wine | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Bernd Steinhauser (linux) |
| Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | regressions, tiwai |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 6.1.4 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
lsusb -v -d 0a12:1004
Output of alsa-info.sh Output of aplay -v -Dplughw:Leaf --period-size=200 --buffer-size=500 message.wav |
||
|
Description
Bernd Steinhauser
2023-01-10 14:45:18 UTC
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. |