From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753031AbbKJNzq (ORCPT ); Tue, 10 Nov 2015 08:55:46 -0500 Received: from mail1.bemta3.messagelabs.com ([195.245.230.172]:47784 "EHLO mail1.bemta3.messagelabs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752497AbbKJNzo (ORCPT ); Tue, 10 Nov 2015 08:55:44 -0500 X-Env-Sender: Adam.Thomson.Opensource@diasemi.com X-Msg-Ref: server-14.tower-39.messagelabs.com!1447163732!5094844!1 X-Originating-IP: [94.185.165.51] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked From: "Opensource [Adam Thomson]" To: Mark Brown , "Opensource [Adam Thomson]" CC: Liam Girdwood , Jaroslav Kysela , Takashi Iwai , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , "alsa-devel@alsa-project.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Support Opensource" Subject: RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Thread-Topic: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Thread-Index: AQHRF7bMwuwKa2yx+U2JlonnXkDOk56NjZEAgAFKp+CAAAL4gIAAA1eQgAAF7oCAABXzcIAC+EKAgAGxqVCAABrEgIABjS5g Date: Tue, 10 Nov 2015 13:55:30 +0000 Message-ID: <2E89032DDAA8B9408CB92943514A0337D460CEA5@SW-EX-MBX01.diasemi.com> References: <01a9b6e96b66327cf9a27781c13aa50545380acb.1446718490.git.Adam.Thomson.Opensource@diasemi.com> <20151105152736.GO18409@sirena.org.uk> <2E89032DDAA8B9408CB92943514A0337D460CA0C@SW-EX-MBX01.diasemi.com> <20151106112141.GE18409@sirena.org.uk> <2E89032DDAA8B9408CB92943514A0337D460CA3D@SW-EX-MBX01.diasemi.com> <20151106115451.GG18409@sirena.org.uk> <2E89032DDAA8B9408CB92943514A0337D460CAAD@SW-EX-MBX01.diasemi.com> <20151108103429.GC6746@sirena.org.uk> <2E89032DDAA8B9408CB92943514A0337D460CC6C@SW-EX-MBX01.diasemi.com> <20151109140225.GA26072@sirena.org.uk> In-Reply-To: <20151109140225.GA26072@sirena.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.26.15] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tAADto3r002618 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? {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Opensource [Adam Thomson]" Subject: Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Date: Tue, 10 Nov 2015 13:55:30 +0000 Message-ID: <2E89032DDAA8B9408CB92943514A0337D460CEA5@SW-EX-MBX01.diasemi.com> References: <01a9b6e96b66327cf9a27781c13aa50545380acb.1446718490.git.Adam.Thomson.Opensource@diasemi.com> <20151105152736.GO18409@sirena.org.uk> <2E89032DDAA8B9408CB92943514A0337D460CA0C@SW-EX-MBX01.diasemi.com> <20151106112141.GE18409@sirena.org.uk> <2E89032DDAA8B9408CB92943514A0337D460CA3D@SW-EX-MBX01.diasemi.com> <20151106115451.GG18409@sirena.org.uk> <2E89032DDAA8B9408CB92943514A0337D460CAAD@SW-EX-MBX01.diasemi.com> <20151108103429.GC6746@sirena.org.uk> <2E89032DDAA8B9408CB92943514A0337D460CC6C@SW-EX-MBX01.diasemi.com> <20151109140225.GA26072@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20151109140225.GA26072@sirena.org.uk> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Mark Brown , "Opensource [Adam Thomson]" Cc: Mark Rutland , "devicetree@vger.kernel.org" , "alsa-devel@alsa-project.org" , Support Opensource , Pawel Moll , Ian Campbell , "linux-kernel@vger.kernel.org" , Takashi Iwai , Liam Girdwood , Rob Herring , Kumar Gala List-Id: devicetree@vger.kernel.org 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?