Hi, Sebastian Reimers recently reported issues with the f_uac2 gadget with BBB's musb stack when connected to a Linux host, with the host in capture and the gadget in playback mode. I had a look, and can confirm two independent issues. a) Linux snd-usb-audio currently pre-calculates the estimated packet sizes to expect from a USB device, and will only receive packets that have the expected size or are smaller. f_uac2, however, always sends packets with 512 bytes, which leads to Babble (-EOVERFLOW) errors on the host side. This can be worked around by setting the UAC_EP_CS_ATTR_FILL_MAX in the UAC2 endpoint descriptor, which makes snd-usb-audio prepare its receive buffers for the endpoint's wMaxPacketSize. This is admittedly something we should also fix on the other side, because the assumption that a device will never send bigger packets than what was estimated might bite us on other devices, too. For now, I'd consider setting the mentioned bit on the gadget side an acceptable fix. b) snd-usb-audio queues IN urbs for capture streams, and once they return, it processes all the audio payload and re-submits the urbs immediately. There is no timing mechanism in this logic that would delay the re-submission of URBs in order to approximate to the configured sample rate. To my knowledge, there was never any such code in that driver. As f_uac2 also has no mechanism for timekeeping, what happens atm is that the gadget ACKs every IN urb from the host with packets of 512 bytes, which in turn makes the virtual audio interfaces run at the maximum possible speed (~ 3x the actual sample rate in my tests). While this works fine when both sides operate on files sinks and sources, things go badly wrong as soon as any side expects data to flow in approximately the configured sample rate. In such cases, one of the virtual audio interfaces will either have buffer overruns or underruns. To fix this, implement a simple time tracking logic, and send 0-byte packets from agdev_iso_complete() if the time passed since the last completed buffer does not allow for another one to be sent. This results in very stable timing behavior in my tests. Patch 1/4 and 2/4 are just cleanups that I did before fixing the issues described above. The series is intended for Felipe's current 'next' branch. Best regards, Daniel Daniel Mack (4): usb: gadget: f_uac2: restructure some code in afunc_set_alt() usb: gadget: f_uac2: add short-hand for 'dev' usb: gadget: f_uac2: set UAC_EP_CS_ATTR_FILL_MAX in bmAttributes usb: gadget: f_uac2: tie capture clocking to system clock drivers/usb/gadget/function/f_uac2.c | 103 +++++++++++++++++++++-------------- 1 file changed, 62 insertions(+), 41 deletions(-) -- 2.1.0 -- 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
