[alsa-devel] [RFC] ALSA vs. dedicated char device for a USB Audio Class gadget driver

[Steve Calfee]

On Thu, May 14, 2009 at 1:58 PM, Laurent Pinchart
<laurent.pinchart at 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