On Tue, Aug 26, 2014 at 1:38 AM, Daniel Mack <dan...@zonque.org> wrote: > On 08/25/2014 09:00 PM, Jassi Brar wrote: >> On Mon, Aug 25, 2014 at 11:40 PM, Daniel Mack <dan...@zonque.org> 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. > Cool... we can avoid runtime calculations by maybe picking the pre-defined 'length pattern' at module load time to match the rate selected. And have those many usb requests allocated and their 'length' initialized to the pattern. Then the rest of code would remain unchanged. Though I won't be surprised if you have some better idea.
>>> 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, Its just the we wouldn't want the fix to get delayed with the data-rate fix patch. Also maybe stable should be CC'ed on that patch? Regards, Jassi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
