> >> 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.


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...


Reply via email to