Hi,
Dne 08. 09. 21 v 10:21 Pavel Hofman napsal(a):
Hi,
The current audio gadget has no way to inform the gadget side that the host side has started playback/capture and that gadget-side alsa processes should be started.
Playback/capture processes on the host side do not get stuck without the gadget side consuming/producing data (OUT requests are ignored in u_audio_iso_complete, IN ones send initial zeros in their req->buf).
However, playback/capture processes on the gadget side get stuck without the host side sending playback OUT packets or capture IN requests and time out with error. If there was a way to inform the gadget side that playback/capture has started on the host side, the gadget clients could react accordingly.
I drafted a simple patch for u_audio.c which defines read-only boolean ctl elems "Capture Requested" and "Playback Requested". Their values are set/reset in methods u_audio_start_capture/playback and u_audio_stop_capture/playback, i.e. at changes of respective altsettings from 0 to 1 and back. Every ctl elem value change sends notification via snd_ctl_notify. The principle works OK for capture/playback start/stop on the host, as monitored by alsactl:
pi@raspberrypi:~ $ alsactl monitor hw:UAC2Gadget node hw:UAC2Gadget, #4 (3,0,0,Capture Requested,0) VALUE node hw:UAC2Gadget, #4 (3,0,0,Capture Requested,0) VALUE node hw:UAC2Gadget, #3 (3,0,0,Playback Requested,0) VALUE node hw:UAC2Gadget, #3 (3,0,0,Playback Requested,0) VALUE
However at enumeration the USB host switches both playback and capture altsettings repeatedly, generating "fake" events from the gadget side POW. The host even sends regular-sized EP-OUT packets filled with zeros during enumeration (tested on linux only for now).
Please is there any way to "detect" the enumeration stage to mask out the "fake" playback/capture start/stop events?
The attached patch does not apply cleanly to mainline u_audio.c because it's rebased on other patches not submitted yet but it's only a discussion inducer for now.
Thanks a lot,
Pavel.