lkml.org 
[lkml]   [2015]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
On Tue, Nov 10, 2015 at 04:21:04PM +0000, Opensource [Adam Thomson] wrote:
> On November 10, 2015 15:45, Mark Brown wrote:

> > That seems like a particularly unfortunate choice given that
> > VOICECOMMAND is used in the standard Google headset mapping (see
> > ts3a227e for an example, that's a device specifically aimed at providing
> > accessory detection in Chromebooks). There's also been some pushback
> > against using the input devices due to the difficulty in enabling apps
> > to access input devices - ALSA controls were preferred instead but
> > that's less helpful for tinyalsa. Perhaps that can be added relatively
> > easily, or a uevent or something.

> I chose VOICECOMMAND as I thought this kind of feature might offer the same kind
> of use as the physical button, but if this only for Google headset use then fair
> enough.

No, that's a generic button but the point is that the expected workflow
from userspace is going to be different if the user pressed a button to
initiate a voice command compared to if they use an activation phrase.

> > Not sure what the best way forward here is, the other implementations of
> > this that I'm aware of do more of the detection in offload and present
> > streams of detected audio to userspace via normal capture.

> Yes, this is far more simplistic, and any voice processing or capture is not
> handled by the codec. It just an indication of above threshold noise level at
> the mic. For the implementations you know of, how are those events indicated to
> user-space?

I'm not aware of any implementations that just do the activity
detection. I've seen hardware with it but nobody using it in software.

> > I would at least suggest moving this into a separate patch and doing
> > the integration separately.

> Are you happy for me to leave the actual controls for this feature in, without
> the user-space reporting side? Otherwise it's a pain to strip that out, and then
> re-instate later. The event can be masked off until the user-space reporting
> is added in a subsequent patch.

Possibly, let's see what the code looks like.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2015-11-10 18:01    [W:0.672 / U:0.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site