On 08/25/2014 09:00 PM, Jassi Brar wrote: > On Mon, Aug 25, 2014 at 11:40 PM, Daniel Mack <daniel@xxxxxxxxxx> wrote: >> Sure, but rates across devices will never match, so it doesn't matter >> really. Two clocks on two devices will always drift, even if they're >> totally accurate by their own means. You have the same situation the >> other way around on the playback endpoint: the host plays at whatever >> speed it considers to be 176400 bytes/sec, which will never be exactly >> 176400 bytes/s measured by the gadget's clock, because there is no >> feedback endpoint. Audio applications have to be aware of that, and if >> they need to synchronize two devices with their own clock each, they >> have to implement some sort of resampler. >> > A high-end device, that consumes exactly 176400 bytes per second, on > host is piped data captured from f_uac2. However we write the code so > that f_uac2 can send only 176000 bytes every second. > > Theoretically ruing out 'perfection' unsettles me. We can do better > and is not much trouble. Alright, you're right. I'll cook something up to alternate the sizes in order to get closer. Will be part of v3. >> Exactly, but with 65536 bytes in the DMA buffer, and 176 bytes in each >> packet, you will have an uneven wrap around around each 372th packet, so >> we need to address these cases. >> > I see, thanks. That is a bug fix then, and probably should have been > patch-3/4 instead. It hasn't been a problem since, but only after the packet size change. But I can swap them around, no problem :) Thanks, Daniel -- 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
