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.
��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
