Hi, Robert Bielik <Robert.Bielik@xxxxxxxxx> writes: >> >> 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... I guess UAC1 doesn't need feedback endpoints, right? Seems like that should be something specific to UAC2. At least for now. -- balbi
Attachment:
signature.asc
Description: PGP signature
