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