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. > 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. 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. Best regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
