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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2E89032DDAA8B9408CB92943514A0337D460CEA5@SW-EX-MBX01.diasemi.com>
Date:	Tue, 10 Nov 2015 13:55:30 +0000
From:	"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@...semi.com>
To:	Mark Brown <broonie@...nel.org>,
	"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 November 9, 2015 14:02, Mark Brown wrote:

> > > What I'm trying to figure out here is if this depends on the audio
> > > routing at runtime or if it's got dedicated configuration?
> 
> > This feature is available for any/all mics connected. Which mics are enabled
> > is a runtime configuration of routing, so to me it makes sense also that we can
> > configure which channel triggers an event, based on our scenario at that time.
> 
> 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?