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

[Laurent Pinchart]

Hi Steve,

On Thursday 14 May 2009 23:12:41 Steve Calfee wrote:
> On Thu, May 14, 2009 at 1:58 PM, Laurent Pinchart
> > 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.

The USB side is already implemented. I need an isochronous endpoint with a 
packet size just a bit bigger than what would be required by the sample rate. 
The amount of data per packet will vary (some might even be empty), but that 
won't be a problem.

I now need to fill the packets with data. When a packet has been successfully 
transferred on USB the USB device controller will notify me with an interrupt. 
I then have to copy audio data from the ALSA ring buffer to the USB request 
buffer and queue the request for transmission (a USB request, in the USB 
gadget device driver terminology, is a data structure that describes a USB 
transfer).

To copy data from the ALSA ring buffer I need to know how much data is 
available at that particular moment, in order to avoid buffer underruns. I'm 
still not sure how to do that.

> 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.

Challenges are usually interesting :-) With a little luck part of the 
complexity will be handle outside the UAC gadget driver, either on the host 
side or by the userspace application on the device side.

Best regards,

Laurent Pinchart