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

[Laurent Pinchart]

Hi Clemens,

On Monday 18 May 2009 10:39:24 Clemens Ladisch wrote:
> Laurent Pinchart wrote:
> > The applicable techniques require knowledge of both the audio clock and
> > the SOF clock in a common place. My driver has no access to the audio
> > clock. All it knows about is the SOF clock.
> >
> > There are only two options I can think of.
> >
> > The first one is to use an asynchronous endpoint and sent the occasional
> > smaller or bigger packet (or duplicate/drop one sample). As the driver
> > can't access the audio clock it needs to derive the information from the
> > amount of data present in the ALSA ring buffer. To be honest I'm not sure
> > if that will be possible at all, as the application will write data at a
> > non-constant rate.
>
> The ALSA API assumes that the device controls the audio clock and that
> the application derives its own speed from that, not the other way
> round.

That's a sensible requirement for a sound card. I now know that my use case is 
out of ALSA's bounds :-)

> > The second one, which sounds easier, at least on the driver side, is to
> > use a synchronous endpoint with a fixed packet size. The application will
> > perform rate matching (duplicating/dropping a sample or resampling the
> > audio stream) using the audio clock and the SOF clock. What I'm still
> > unsure about is how the application can access the audio clock and the
> > SOF clock through ALSA, but I suppose that's possible.
>
> The ALSA API doesn't give you access to the SOF clock.

Does the ALSA API give applications access to the audio clock ? As Alan Stern 
mention in his e-mail, does ALSA allow an application to resample audio from 
an ALSA source (microphone on sound card 1) before sending it to an ALSA sink 
(speaker on sound card 2) ?

> What you want to do is not possible (or impracticably hard) with the
> ALSA API; I strongly suggest that you define your own API for your
> audio gadget driver so that SOF clock information is made available to
> the application, and that packet sizes can be directly controlled by the
> application.

I'll have a look at that. ALSA was appealing because of the existing user base 
and its ability to transfer audio data from/to userspace applications. I knew 
it hasn't been designed with my use case in mind, so I didn't close to door to 
using a custom API, but I still wanted to give it a try.

Best regards,

Laurent Pinchart