On Fri, 22 Sep 2023, at 3:09 AM, Pavel Hofman wrote: > Dne 21. 09. 23 v 3:30 Arun Raghavan napsal(a): >> 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? > > The current version uses the Playback/Capture Rate alsa ctls with > notifications > https://lore.kernel.org/all/20220121155308.48794-8-pavel.hofman@xxxxxxxxxxx/ > > Example of handling is e.g. https://github.com/pavhofman/gaudio_ctl , > the controller is being used in a number of projects, mostly DIY. > > Recently Qualcomm devs have submitted patches for alternative approach > using uevents > https://lore.kernel.org/lkml/2023050801-handshake-refusing-0367@gregkh/T/#mcd6b346f3ddab6ab34792be0141633bb362d168f > and later versions. The detection is identical, monitoring change in > altsetting from 0 to non zero and back (methods > u_audio_[start/stop]_[capture/playback]), just a different means of > communicating the events to userspace. > > Both methods (using the same principle) suffer from not knowing what's > going on the host side and cannot differentiate between player really > starting playback vs. UAC2 host driver or Pulseaudio shortly checking > device availability. That's why the gaudio_ctl controller can debounce > the playback/capture start > https://github.com/pavhofman/gaudio_ctl#debouncing . But that is just an > ugly workaround... Thank you for the links, Pavel! This all makes sense. I guess the uevent mechanism is more "general" than the ALSA ctl for clients that want to plug in, listen and do $something. Not sure if there are other pros/cons of either approach. I wonder if it might not be good to have some debouncing in the kernel rather than having every client have to implement this. Cheers, Arun
