> >> Indeed, that's also mandated by USB spec. Seems like we need to patch > >> f_uac2.c. Can you check if setting the IN endpoint as implicit feedback > >> data is enough? > > > > Just tried your proposed patches on 4.15.1 (with an RPi Zero) and with > > g_audio, unfortunately there is no change. Device is still not > > recognized, and having the same error code. > > > > So, a real feedback IN endpoint is needed ☹ > > I'll see if I can reproduce this here. Perhaps someone in the office has > Windows 10, who knows.
Great! Regarding feedback (IN) endpoint: With the current architecture, i.e. UAC2 gadget connecting to ALSA subsystem, I think the implementation of a feedback endpoint should only need to return (fs/1000)/8 (i.e. number of frames per 125 us), so in case of fs = 48000, feedback should return 6, and for 44100 it would be 5.5125 (with 3 bytes encoded in 10.14 format). Unfortunately I have yet no idea where in the gadget driver hierarchy this stuff should be implemented. Should it be f_uac2.c ? Afaict, the endpoints themselves are declared in struct g_audio (u_audio.h), so that struct should be extended with a feedback_ep ? Learning as I go along... Regards /Robert