At 7:22 AM +0800 11/16/12, Daniel Mack wrote:
Hi Daniel, Hi Elad,
On 16.11.2012 05:32, Daniel Griscom wrote:
At 10:02 PM +0100 11/15/12, Eldad Zack wrote:
Hi Daniel,
On Thu, 15 Nov 2012, Daniel Griscom wrote:
I'm having trouble getting implicit feedback working with my custom capture/playback USB audio class device, even with the latest kernel. I presume it's a problem with my device's configuration, but can't figure out exactly what the problem is (after a whole lotta investigation).
What exactly doesn't work?
The audio output stream (from the computer to my device) runs at a few frames per second higher or lower rate than that of the input stream (from my device to the computer). The actual difference seems to be stable on a specific machine, but varies greatly between machines (I've seen differences from +7fps to -2fps; I presume this is due to differences in CPU clock frequencies).
So you're saying that this is what you experience after you added code to make the driver use the implicit feedback mechanism? Over which time did you measure this and how exactly? Because frankly, I doubt that - the data rate is purely derived from the number of incoming samples.
This has been the case for a while; we started work with ALSA 1.0.23, but upgrading to kernel 3.6.6 (with included ALSA code) didn't change anything. We have yet to do any patching of ALSA for this matter.
Does your device demand the same number of *bytes* or samples/channel to be sent?
I'll have to check that.
Is there any commercial USB hardware out there that supports implicit feedback? I assume the ALSA developers are testing against something, but I can't find anything appropriate.
I'm not an ALSA dev, but I recently posted a series of patches for the M-Audio Fast Track C400, which uses the implicit feedback code that was already in the tree for other devices.
Yes, sorry for not responding. I've seen this, but didn't have time yet to respond. Thanks for doing this.
So, this device uses implicit feedback to tell ALSA to send output data at the same rate as its input data? Very cool; I've ordered one to test.
The code I wrote for implicit feedback is used by the M-Audio FTU devices,
So, with an FTU the implicit feedback code works? What version of kernel/ALSA should I use - the latest?
although I would actually not recommend buying one.
Too late...
Take a look at sound/usb/pcm.c, there are quite a few hints to how this is discovered currently.
We've been looking there already, but will dig deeper.
I might help if you posted a patch with the changes you made to support your device.
No such patch.
AudioStreaming Interface Descriptor: bLength 17 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 3 Discrete tSamFreq[ 0] 32000 tSamFreq[ 1] 44100 tSamFreq[ 2] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback DataNote that I never tested the automatic discovery of that mode. The device I wrote the code for doesn't announce it that way, and so a quirk was needed in pcm.c to make it happen. Ideally though, what you did is the right thing to do, just just need to make sure the driver really obeys that setting :)
Well, that's good to know anyway.
Lots to think about, and thanks, Dan