On Thu, May 14, 2009 at 1:58 PM, Laurent Pinchart laurent.pinchart@skynet.be wrote:
Hi Hal,
first of all, thanks for your answer.
On Thursday 14 May 2009 20:18:07 Hal Murray wrote:
I need an API to transfer audio data from userspace to kernelspace. I initially thought about ALSA, but it turns out some assumptions made by ALSA are not fulfilled by my system. One of the most serious problems is that the UAC gadget driver doesn't have any audio clock. The only hardware clock available is the USB device controller interrupts generated at the USB transfer rate, and those are much faster than the audio sample rate. This will cause buffer underruns that I need to handle.
You don't need a clock. The data will come to you at the right rate. All you need to do is pass it on when you have enough to fill up a buffer. The buffer size is fixed. It's part of the spec for the device you are emulating.
I'm not emulating any device. The buffer size is up to me, and I actually have a fixed number of small buffers, but that shouldn't make a difference.
Hi Laurent,
The problems might be clearer to you if you do the output side first. You have to define one or more alt/interfaces with isoc OUT sizes to match the sample rate. Some rates are straight forward and don't care much about the buffer/packet sizes like 45,000 HZ. However the 44100 hz rate (and 22050 and 11025) made popular by CDs is interesting because it doesn't divide by 1000, the FS frame rate. So a driver must output 9 packets of 44 samples (times the number of bytes in sample width times stereo/mono) and 1 of 45 samples. Typically USB chips determine the sample rate by the interface and the number of bytes coming per frame.
This is a challenging project, compounded by the audio usb class spec. In my opinion audio is the worst, hardest to understand spec. Second is the HID-PID spec.
Regards, Steve