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