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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
