[alsa-devel] [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20151110/24c3c362/attachment-0001.sig>