Re: RFC: usb: gadget: u_audio: Notifying gadget that host started playback/capture?
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.
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
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@ivitera.com/
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/#mc... 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...
With regards,
Pavel.
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@ivitera.com/
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/#mc... 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
Dne 05. 10. 23 v 1:15 Arun Raghavan napsal(a):
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,
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@ivitera.com/
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/#mc... 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.
If the gadget defines multiple samplerates, the client must look at the RATE alsa ctls for learn the actual rate requested by the host. The ctls provide both the rate and notification of playback/capture start/stop at the same time.
For gadgets with a single fixed samplerate, the alsa ctl vs. uevents methods are equivalent. Both may find their users and can be in the gadget code, IMO.
I wonder if it might not be good to have some debouncing in the kernel rather than having every client have to implement this.
I am afraid this would be a large feature (debouncing requires extra threads), I have not even tried to push it through. Much better would be having some nice solution instead of a workaround :-)
With regards,
Pavel.
On Thu, 5 Oct 2023, at 10:30 AM, Pavel Hofman wrote:
Dne 05. 10. 23 v 1:15 Arun Raghavan napsal(a):
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,
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@ivitera.com/
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/#mc... 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 wonder if it might not be good to have some debouncing in the kernel rather than having every client have to implement this.
I am afraid this would be a large feature (debouncing requires extra threads), I have not even tried to push it through. Much better would be having some nice solution instead of a workaround :-)
Makes sense.
Maybe a silly question, but what is the status of these patches -- I see them as "Accepted" on patchwork but they've not actually landed upstream yet?
Regards, Arun
On Wed, 25 Oct 2023, at 12:33 PM, Arun Raghavan wrote: [...]
Maybe a silly question, but what is the status of these patches -- I see them as "Accepted" on patchwork but they've not actually landed upstream yet?
Definitely a silly question, this has been upstream since 5.17, just missed that somehow. Sorry about the noise, all.
Thanks! Arun
participants (2)
-
Arun Raghavan -
Pavel Hofman