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