Created attachment 288981 [details] Output of alsa-info.sh This originated from https://github.com/telegramdesktop/tdesktop/issues/1548 It looks like all affected people are running some sort of USB audio interface, mostly a Focusrite Scarlett. So when I play something back with say 44100 Hz and then while playback is still running start recording with the same audio interface, but at a different rate, say 48000 Hz, then the output sound is heavily distorted. This is 100% reproducible via ALSA only: - aplay -D 'hw:2,0' -f S32_LE --channels=2 --rate 44100 /tmp/somemusic.raw # plays back at requested 44100 Hz - wait a second, then issue the following command - arecord -D 'hw:2,0' -f S32_LE --channels=2 --rate 48000 /tmp/out # records at requested 48000 Hz The heavily distorted sound arises immediately when issuing the arecord command. When running the arecord command with --rate 44100, the problem does NOT arise. When stopping the buggy playback while keeping the arecord running and then starting the same aplay again, the sound is perfect. Here is some information on my system: - Audio Interface: Focusrite Scarlett Solo USB 3rd Gen connected via USB 3.0 - Attached is the output of alsa-info.sh
Hi, since noone seems to be answering, I can try to fix this myself. I would appreciate any pointers on how to debug this though. Any tips on where to start with this?
You might need to apply the similar quirk like Scarlett Solo 2nd gen (1235:8205). Take a look at sound/usb/* and look for 0x1235 (especially sound/usb/quirks.c). There are a few codes that are specific to those devices.
Created attachment 289435 [details] Not-working sync mode patch Similar to the Scarlett Solo 2nd gen, in the attached patch (on top of v5.6.15) I tried forcing the Scarlett Solo 3rd gen to use Synch: Asynchronous mode, but unfortunately the distorted audio still occurs.
Fwiw, this issue isn't exclusive to Focusrite Scarlett audio interface. I have a Steinberg UR22 and I have the same issue.
Created attachment 290587 [details] FFT noise analysis If anyone needs this for debugging, attached is a FFT analysis of the distorted audio while playing back a pure 440 Hz sine wave. The peak in the middle is 440 Hz, but there are several other non-related frequencies visible too. Note that I had to record this by using a mic next to my audio output, as a recording directly from the digital Alsa audio monitor did not include the distorted audio. So some background noise is included.
I'm affected by this issue using a Scarlett Solo 3rd gen. Though this was found through Telegram triggering this behavior, this also impacts users who use software like OBS (which is how I discovered it).
Could you give the lsusb -v output of the Scarlett device? It's possibly the lack of the implicit feedback sync. The latest changes for 5.11 kernel include the improvement of the implicit feedback support, and hopefully it works better for this device, too. If the implicit fb mode isn't set, we'd need to apply some quirk to enable it.
Created attachment 294055 [details] lsusb.txt Hi, attached is the output of lsusb -v -d 1235:8211. Great to hear of this improvement in 5.11. I will test it as soon as 5.11 releases. Am Wed, Dec 09, 2020 at 03:24:33PM +0000 schrieb bugzilla-daemon@bugzilla.kernel.org: >https://bugzilla.kernel.org/show_bug.cgi?id=207617 > >--- Comment #7 from Takashi Iwai (tiwai@suse.de) --- >Could you give the lsusb -v output of the Scarlett device? > >It's possibly the lack of the implicit feedback sync. The latest changes for >5.11 kernel include the improvement of the implicit feedback support, and >hopefully it works better for this device, too. If the implicit fb mode isn't >set, we'd need to apply some quirk to enable it. > >-- >You are receiving this mail because: >You reported the bug.
BTW, what the implicit feedback implies: you can't use the different sample rates for playback and capture simultaneously. The recent driver implementation enforces the compatible parameters in such operational mode.
I switched my system from Pulseaudio to Pipewire and I no longer experience this bug. I'm also on kernel 5.11.8, so maybe there's a coincidence somewhere, but I think Pipewire works around this bug somehow.
I guess it's just a matter of what parameters the system uses and/or which kernel it is. As mentioned, 5.11.x series received a fair amount of changes in USB-audio driver regarding the implicit feedback implementation, and this might cover your case. Or possibly pipewire enforces the same parameters for both playback and capture directions casually.
I have the same(?) issue on a USB Behringer UMC404HD. I'm running Fedora 34 with kernel 5.14.16-201.fc34.x86_64. What I experience is this: 1) start the playback PCM at 44100Hz, file plays fine 2) start capture PCM at 48000Hz 3) pitch of playback changes, likely to 48KHz. captured sound is still fine. This other scenario also fails but on the capture side: 1) start capture PCM at 48000Hz, captures at 48KHZ 2) start the playback PCM at 44100Hz, file plays fine 3) a blip of noise in recording and pitch of recording changes, likely to 44.1KHz This is normally not a problem in PipeWire because we enforce one single sample rate (48KHz) on all pcms. You can manually override this and then run in the above errors. So it seems that the last PCM to be opened dictates the sample rate of all PCMs on that card. I have a working patch to enforce the same sample rate on all pcms from the same card and it seems to avoid this problem. I have some questions, though: * Is enforcing the same sample rate on all pcms of a card the right approach? * Is this likely a hardware limitation? * Is there any way alsa-lib can narrow down the allowed rates when the hardware has this limitation? * Is there any other way to let user space know about this limitation?
(In reply to Wim Taymans from comment #12) > * Is enforcing the same sample rate on all pcms of a card the right approach? Definitely not for the applications. The driver should reduce the configuration space according the hardware limitations. Most hardware is capable the independent rate usage for PCM streams. The applications should not make any assumptions. > * Is this likely a hardware limitation? Yes. > * Is there any way alsa-lib can narrow down the allowed rates when the > hardware has this limitation? You can limit the rate in the alsa-lib configuration. But the driver should send the right configuration available at the specific time (when other PCM streams are active for example). > * Is there any other way to let user space know about this limitation? The USB driver should be fixed for this device (add a quirk when the vendor has bad or incomplete USB descriptors). I would open a new specific bug for this device and add output from `alsa-info.sh --no-upload` there for the analysis.
With 5.16-rc2 I cannot reproduce this anymore on my card, see also https://bugzilla.kernel.org/show_bug.cgi?id=215123
Do you know what commit fixed the issue and whether that commit fixes it for all USB audio interfaces or only for your specific interface? Am Fri, Nov 26, 2021 at 10:51:07AM +0000 schrieb bugzilla-daemon@bugzilla.kernel.org: >https://bugzilla.kernel.org/show_bug.cgi?id=207617 > >--- Comment #14 from Wim Taymans (wim.taymans@gmail.com) --- >With 5.16-rc2 I cannot reproduce this anymore on my card, see also >https://bugzilla.kernel.org/show_bug.cgi?id=215123 > >-- >You may reply to this email to add a comment. > >You are receiving this mail because: >You reported the bug.
Likely this one 4e7cf1fbb34ecb472c073980458cbe413afd4d64 "ALSA: usb-audio: Restrict rates for the shared clocks" With link https://bugzilla.suse.com/show_bug.cgi?id=1190418
The fix was also backported to 5.15.x. Let's close.