Hi Jassi, On 08/19/2014 11:52 AM, Jassi Brar wrote: > Its been quite some time now, but I think we designed the uac2 to rely > on USB's ISO packets' rate control to send and receive audio data at > announced sampling rate. I'm still thinking how that setup should have ever been possible with snd-usb-audio on the host side. snd-usb-audio prepares its capture USB ISO frames with a pre-calculated value of how many bytes per packet to expect on the capture endpoint. That value is derived from the currently configured sample rate, and if the sound card fills each of its buffers with that number of bytes or less, everything's fine. Also, each urb is resubmitted immediately after reception, and there is no delay or timing or anything. f_uac2, however, currently always completes its buffers with 512 bytes packets, 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, but once any part of the system expects the actual rate to be at least approximately in the configured range, things go wrong of course. Also, the maximum number of bytes that the host expects to receive for a packet is not part of the request communication on the USB wire. Even if we wanted, we wouldn't be able to adopt to it in order to prevent overflows on the host side. My current fix is comprised of two parts: a) set UAC_EP_CS_ATTR_FILL_MAX in the capture UAC2 endpoint, which allows the gadget to actually send packet with wMaxPacketSize bytes, and b) implement a simple timing mechanism to tie the gadget's capture stream to the configured sample rate, and send 0 bytes packets if the timing doesn't allow a full-sized packet to be sent again. These two changes fixed the functionality on a BBB/musb gadget setup, but I'd still like to understand how this could have ever worked the way it's implemented at the moment. Which OS did you test with on the host side, and what type of gadget hardware was in use? I'll send out the patches once I have confidence that I'm not missing anything essential :) 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
