Bug 207617
Summary: | Distorted audio when recording input with different sample rate than output | ||
---|---|---|---|
Product: | Drivers | Reporter: | magnus.gross |
Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | CC: | alex765, espogabe, tiwai, wim.taymans |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 5.6.10 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
Output of alsa-info.sh
Not-working sync mode patch FFT noise analysis lsusb.txt |
Description
magnus.gross
2020-05-07 20:25:57 UTC
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. |