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@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.
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.
