Re: RFC: usb: gadget: u_audio: Notifying gadget that host started playback/capture?

["Arun Raghavan" <arun@arunraghavan.net>]

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