On Sat, Nov 14, 2009 at 18:33, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sat, 14 Nov 2009, Javier Kohen wrote: > >> > I tracked a problem I'm having with my USB audio DAC down to >> > patch cb88a1b887bb8908f6e00ce29e893ea52b074940. > > Are you certain? That patch did not change anything important; mostly > it just renamed some functions. I can't be sure, but the evidence seems to support that: 1) I won't claim to understand this code because it's the first time I look at it, but it seems to do more than a rename. It adds a new callback/interface, and it moves a spinlock down within a code block. 2) Git bisect confirmed the issue, with no bias on my part. Even though just by looking at the changelog between versions 2.6.30.4 (known good) and 2.6.30.8 (known bad), I had a strong hunch this patch was the culprit. I don't know enough to say whether the bug is in this patch, or if this patch just triggers it (e.g. by calling a broken callback that wasn't being called before). What I know is that the problem didn't happen before this patch, and it happens 100% of the time with this patch. > >> > This issue is present in kernels 2.6.30.6+, 2.6.31.* and 2.6.32-rc7. >> > >> > With this patch applied, some combinations of two programs communicating >> > with the DAC cause the audio to vanish. The only way to restore it seems to >> > be to close all applications that have the DAC's devices open. After this, >> > all goes back to the previous functional state, though the bug can be >> > reproduced again by following the same steps. >> > >> > All audio applications I have use ALSA directly. I'm not running PulseAudio, >> > ESD or any other kind of audio daemon. I don't have other sound cards in the >> > system, except for the motherboard's on-board, which is disabled from the >> > BIOS. Some easy ways in which I can reproduce this problem: >> > >> > 1) Start playing sound with totem/gstreamer, or sox' ALSA driver (run "play" >> > from the command-line). >> > 2) Start alsamixer. Boom, the device goes silent. > > Can you post a usbmon trace showing what happens when you run this > test? Sure. They're small enough, so I've attached it to this mail. I'm also including the output of lsusb -vv for this bus (the hub on the monitor). > > >> > ALSA recognizes the DAC as "Burr-Brown Japan PCM2702." Currently this DAC is >> > connected to my computer through the USB hub in my monitor, which makes it >> > go through the EHCI driver. When connected directly to the motherboard the >> > DAC uses the OHCI driver, which doesn't exhibit this problem. However, there >> > is a problematic interaction between the DAC and the OHCI driver or >> > motherboard chipset (nVidia's CK804), which causes the audio to degrade >> > after a while. The degradation appears first as a background hiss, until it >> > turns into a "broken radio" kind of sound. If anyone would like to track >> > down the problem with OHCI, I'm more than willing to give further details >> > and assistance. My intuition tells me this is an USB issue, not ALSA's. > > In any case it's a separate matter, since it involves OHCI and not > EHCI. Sure, but I'm hoping that somebody who could be interested in solving it would read that. I'm not the first user to report it, recently somebody mentioned the same issue on alsa-user.
Attachment:
usbmon-ehci-sound-dac.out.bz2
Description: BZip2 compressed data
Attachment:
lsusb-ehci-sound-dac.out.bz2
Description: BZip2 compressed data
