linux-kernel - Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 10 Nov 2015 16:42:02 +0000
From:	Mark Brown <broonie@...nel.org>
To:	"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@...semi.com>
Cc:	Liam Girdwood <lgirdwood@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Support Opensource <Support.Opensource@...semi.com>
Subject: Re: [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.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)