[alsa-devel] [RFC] ALSA vs. dedicated char device for a USB Audio Class gadget driver
laurent.pinchart at skynet.be
Mon May 18 16:47:41 CEST 2009
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
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
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.
More information about the Alsa-devel