On November 10, 2015 14:15, Mark Brown wrote:
The general userspace expectation is that the detection is always active and consistent rather than varying at runtime - runtime variability might be a bit surprising for it, and even then variability in what is detected based on other settings is a bit surprising. If the hardware is that limited I guess it's about all that can be done but I'm still not clear what the use cases are for configuring the levels (as opposed ot the routing).
How about the example of always on voice in Android, which can be enabled and disabled, depending on user settings, and routing will vary depending on which mic is in use at the time? For the levelling is it not plausible that a user could configure the level based on their current environment. You have moderately loud background noise, then your threshold would want to be higher, but in a quiet environment the likelihood is you would want to lower that threshold?
So this *isn't* a normal mic detection feature? What's the userspace interface for reporting then?
By mic detection you thought this was to detect if a mic was present or not? It's to detect the noise level on a mic and raise an event if the captured sound is above a specific threshold level. Apologies if that wasn't clear.
In the driver code I'm using KEY_VOICECOMMAND, and simulating a press and release of this key, to indicate to user-space. This seemed like the obvious choice for this feature to me, although I'd happily get your opinion on this.