Robert Bielik <robert.bie...@dirac.com> 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.


Attachment: signature.asc
Description: PGP signature

Reply via email to