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

[Alan Stern]

On Sun, 17 May 2009, 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. 

This whole discussion is a little puzzling.

The Gadget API doesn't provide any way to tie the buffer contents of
Isochronous usb_request's to the frame number.  Here's what I mean:
Suppose you want to transfer a new audio data buffer every frame.  You
queue some requests, let's say

	R0 for frame F0
	R1 for frame F1
	R2 for frame F2
	etc.

But what happens if a communications error prevents R0 from being 
delivered during F0?  That's the sort of thing you expect to happen 
from time to time, and Isochronous streams are supposed to handle such 
errors by simply ignoring them.  So ideally you'd like to forget about 
the missing data, and go ahead with R1 during F1 and so on.

But as far as I can see, the Gadget API doesn't provide any way to do
this!  Depending on the implementation of the device controller driver,
you might end up transferring R0 during F1, R1 during F2, and so on.  
Everything would be misaligned from then on.  I don't see any solution
to this problem.

I'd like to answer your questions about synchronizing the USB audio 
stream with an ALSA audio stream, but since I don't know anything about 
how either audio protocol is supposed to work, I can't.  Suppose you 
were trying to write a normal program that accepted data from an ALSA 
microphone and sent it to an ALSA speaker; how would such a program 
synchronize the input and output streams?

Alan Stern