On Wed, 24 Feb 2021 18:57:42 +0100, Jaroslav Kysela wrote: > > Dne 24. 02. 21 v 13:42 Takashi Iwai napsal(a): > > On Wed, 24 Feb 2021 13:08:55 +0100, > > Jaroslav Kysela wrote: > >> > >> Dne 24. 02. 21 v 12:43 Takashi Iwai napsal(a): > >> > >>>>> So far, a user control is merely storing the value, let read/write via > >>>>> the control API. That's all, and nothing wrong can happen just by > >>>>> that. Now if it interacts with other subsystem... > >>>>> > >>>>> A more serious concern is rather the fragility of the setup; for > >>>>> enabling the mute LED control, you'd have to create a new user-space > >>>>> control, the function of the control has to be ignored by some > >>>>> application and some not, etc. This has to be done on each machine > >>>> > >>>> You're using "ignore", but as I explained before, the user space switch will > >>>> be used in the whole chain: > >>>> > >>>> capture stream -> > >>>> alsa-lib mute switch / silence PCM stream -> > >>>> PA mute switch / silence PCM stream > >>>> > >>>> So PA can use this switch like the traditional hardware mute switch. > >>> > >>> Does it mean PA would work as of now without any change? Or does it > >>> need patching? > >> > >> Yes, no PA modifications are required with my mechanism. The PA will just see > >> the new user space control - mute switch - created in alsa-lib - which will be > >> synced the internal PA path mute state like for the hardware mute > >> switch. > > > > OK, but how would we create and manage the user control element? And > > why it has to be user control? > > The softvol or alsactl can create the user control element. The alsa-lib > softvol plugin and PA can silence stream according the state. And that's tricky if it's only with PA, as PA won't open a softvol PCM stream... > I see your point to create this control in the kernel space, but any other > name than "Mic Capture Switch" (in the ACP case) will be misleading for users, > because the user-space does the appropriate real silencing job instead of hw. > > And if we create "Mic Capture Switch" in the kernel space, it may be > misleading for applications (they can think that there's hardware mute control). > > Perhaps, we can create "Mic Phantom Capture Switch" in kernel which may > resolve both problems (no hw mute information + no user confusion). Yes, something like that would work. The advantage of in-kernel implementation is that it's self-contained, so just deploying the new kernel makes everything working. thanks, Takashi
