On December 03, 2015 11:37, Takashi Iwai wrote:
This patch adds support to the codec driver to handle mic level detect related IRQs, and report these to user-space using a uevent variable.
Is the uevent the best way for this?
thanks,
Takashi
Well originally I was using an input device mechanism to report to user-space, albeit using KEY_VOICECOMMAND, which Mark mentioned wasn't correct for this scenario, which was fair enough. He also mentioned that there had been a general push back on using input devices so that code was dropped. See thread below:
https://lkml.org/lkml/2015/11/10/347
uevent seemed like the simplest solution to report this event, and allow user-space to act based on it. As mentioned before though, I am open to suggestions if there's a better way.
I'm not strongly opposing to uevent as long as it's well considered. But then please describe how it's notified properly and why it was chosen. The patch changelog has enough free room to write more details, fortunately. Tell more your story for Christmas :)
In general, you can use an ALSA control notification for this kind of event. But it also depends on the user-space side. With alsa-lib, it's pretty easy to use, while with tinyalsa that lacks of the notifier handling, you'd need to implement more code there.
For a plug/unplug type event, we have a generic jack layer, but this doesn't seem fitting perfectly, either.
For ALSA control notification, this implies there's a control associated, but for this scenario that's really not necessary. You just want to know when the noise level captured at the mic has gone above a certain threshold and then act accordingly (process audio capture stream). There's no real need I can see for a control to read from. As for the jack layer, I agree that it doesn't really fit.
Ok, will update the patch commit message to add more details on this, including references to Santa Claus, reindeer with shining noses, and other festive symbols. :)