Hi Alan, On Sunday 17 May 2009 23:28:20 Alan Stern wrote: > 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. Your analysis is right, but I think I can work around the problem by checking the SOF counter in the USB request completion handlers. If the counter is too much ahead its ideal value I can assume that at least one packet failed to transfer and resulted in a time shift. I will then just drop one packet. Instead of the ideal R0/F0, --/F1, R2/F2, R3/F3, R4/F4, R5/F5, ... situation I will get R0/F0, --/F1, R1/F2, R2/F3, R4/F4, R5/F5, ... > 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? That's a very good question. If an ALSA guru could answer it I would (hopefully) get one step closer to a solution. I can't imagine that ALSA wouldn't support this use case. Best regards, Laurent Pinchart _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
