[alsa-devel] [RFC] ALSA vs. dedicated char device for a USB Audio Class gadget driver
laurent.pinchart at skynet.be
Fri May 15 11:36:52 CEST 2009
thanks for your answer.
On Friday 15 May 2009 09:01:48 Clemens Ladisch wrote:
> Laurent Pinchart wrote:
> > 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.
> This is not how ALSA drivers are supposed to work. The framework was
> designed for DMA devices that run asynchronously and just take data out
> of the ring buffer whenever they need them. Your driver should work in
> the same way, i.e., you queue a packet of data when you need to queue
I know that ALSA is designed for asynchronous operation. This is fine for
devices that provide an audio clock (all sound cards do), but leads to a few
issues for devices that don't, like this one.
When streaming audio data from a file to USB, there is simply no audio clock
in the system. When streaming audio data from a real audio device to USB, the
audio clock comes from the real audio device and is beyond control of the USB
Audio Class gadget driver.
I can see two ways around this.
1. Use an asynchronous isochronous endpoint to stream data. The USB Audio
Class gadget driver will either have to be provided with a clock from
userspace, or stream data as fast as it can, needing a way to check the amount
of data present in the buffer (as explained in my previous e-mail).
2. Use a synchronous isochronous endpoint to stream data. The USB Audio Class
gadget driver will derive its clock from the USB Start Of Frame clock and the
sample rate, and send a fixed number of audio samples per packet. In this case
the userspace application will have to resample audio data to match the source
and sink rates. The issue with this solution is that I'm not sure if the USB
stack provides the necessary information. I need to fill USB packets with
audio data and queue them for transmission, but I don't know when they will be
transmitted, making it difficult to adjust the amount of data per packet based
on the sample rate.
As a side note, I'm not sure how difficult audio rate matching is, I suppose
the userspace ALSA API provides enough information to match rates, but I'd
appreciate if someone could confirm this (and possibly provide a few pointers
to related documentation).
More information about the Alsa-devel