Hi folks, On Fri, 1 Oct 2021, at 8:38 AM, Pavel Hofman wrote: > 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. Resurrecting this one -- is there any input on how we want to deal wit letting UAC gadgets know when the host is sending/receiving data? Cheers, Arun
