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.
