On 08/24/2014 06:26 PM, Jassi Brar wrote: > On Sun, Aug 24, 2014 at 7:26 PM, Daniel Mack <daniel@xxxxxxxxxx> wrote: >> f_uac2, however, currently always completes its buffers with 512 bytes >> packets, > Current uac2 uses the max packset size (which may not be 512 for every > udc) for the EP. Probably it (wMaxPacketSize) should be set to > bytes/ms for the sampling rate. It's actually really common to set wMaxPacketSize to something much higher than the actual payload will be. After all, the device is free to return short packets, and it's even supposed to do. >> which causes two problems: a) it leads to -EOVERFLOW errors on >> the host side, as the host doesn't expect such big packets, and b) audio >> is transported as fast as possible, and nothing ties the actual rate to >> any clock on either side. In my tests, audio was transported roughly at >> 3x the actual sample rate. While this works fine if only files are in >> the game on both sides >> > f_uac2 is a virtual sound card that can not play/record sound to/from > a physical codec ... it's basically just a way to capture audio data > in digital form ;) so 'files' was assumed to be the primary way of > using it. Sure, but audio still required to be 'real-time' :) > The host was Ubuntu latest at that time. Testing method and 'quirks' > are documented in archives > http://www.spinics.net/lists/linux-usb/msg50855.html > We didn't have access to a Mac and Windows wouldn't support UAC2. Ok. With files on both sides, it does in fact work. The use case for the current setup, however, is a real-time streaming device, and hence we have to rely on reasonable timing. Anyway - thanks for the explanations. I'll polish my patches and post them for discussion. 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
