> >> 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
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
