Hi Lewis, Sorry for the long delay! On 02/06/2014 04:38 AM, Lewis Pike wrote: > Here are my kernel details: > > 3.12.7-2-ARCH #1 SMP PREEMPT Sun Jan 12 13:09:09 CET 2014 x86_64 > > Though, I should note that this is not a new problem for me. I've > been seeing this issue since early 2011, when I first began attempting > to use the Fast Track Pro as a capture device under Linux. > > dmesg doesn't print anything when the capture stream begins. Though, > when powering on the device it prints the following: > > [ 278.496714] usb 4-2: new full-speed USB device number 3 using uhci_hcd > [ 278.859181] usb-audio: Fast Track Pro switching to config #2 > [ 278.859192] snd-usb-audio: probe of 4-2:1.0 failed with error -5 > [ 278.862179] usb-audio: Fast Track Pro switching to config #2 > [ 278.862187] snd-usb-audio: probe of 4-2:1.1 failed with error -5 > [ 278.868179] usb-audio: Fast Track Pro config OK > > I am finding that on some power-cycles, the device seems quite stable > and I unable to put it into a bad state. On these power-cycles, I > have been able to run arecord hundreds of times and the captures are > still good. > > In other instances, however, the device will inevitably begin > producing distorted captures. Could you share such a distorted recording maybe? Some seconds would suffice. And do you also have similar trouble on the playback side? Also please check whether that problem affects you in both 16 and 24 bit resolution; according the the USB descriptors, the device offers both modes on different interfaces. I you want to get into debugging this, I'd suggest you hook up some USB tracer under Windows[*] and have a look at the initialization sequence the driver does, and also capture the first in-bound packet. Then compare that to what the Linux driver does. Apply some very low-volume audio on the input (~ -48dB attenuation) during that, so that you can tell from a USB dump whether the audio data alignment inside the USB packet is sane: In such cases, the most significant byte should be in a low range. If it isn't, there's a byte shift in the stream. I could also image a timing issue during initialization, but that's all just speculating for now. Sorry I can't be of more help right now. Daniel [*] http://wiki.wireshark.org/CaptureSetup/USB ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
