From: "Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com> To: Mark Brown <broonie@kernel.org>, "Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com> Cc: Liam Girdwood <lgirdwood@gmail.com>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>, Mark Rutland <mark.rutland@arm.com>, Ian Campbell <ijc+devicetree@hellion.org.uk>, Kumar Gala <galak@codeaurora.org>, "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Support Opensource" <Support.Opensource@diasemi.com> Subject: RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Date: Tue, 10 Nov 2015 16:21:04 +0000 [thread overview] Message-ID: <2E89032DDAA8B9408CB92943514A0337D460CF5D@SW-EX-MBX01.diasemi.com> (raw) In-Reply-To: <20151110154434.GG12392@sirena.org.uk> [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2149 bytes --] On November 10, 2015 15:45, Mark Brown wrote: > > It's to detect the noise level on a mic and raise an event if the captured > > sound is above a specific threshold level. Apologies if that wasn't clear. > > > In the driver code I'm using KEY_VOICECOMMAND, and simulating a press and > > release of this key, to indicate to user-space. This seemed like the obvious > > choice for this feature to me, although I'd happily get your opinion on this. > > 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. > 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 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. ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
WARNING: multiple messages have this Message-ID (diff)
From: "Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com> To: Mark Brown <broonie@kernel.org>, "Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com> Cc: Mark Rutland <mark.rutland@arm.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>, Support Opensource <Support.Opensource@diasemi.com>, Pawel Moll <pawel.moll@arm.com>, Ian Campbell <ijc+devicetree@hellion.org.uk>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Takashi Iwai <tiwai@suse.com>, Liam Girdwood <lgirdwood@gmail.com>, Rob Herring <robh+dt@kernel.org>, Kumar Gala <galak@codeaurora.org> Subject: Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Date: Tue, 10 Nov 2015 16:21:04 +0000 [thread overview] Message-ID: <2E89032DDAA8B9408CB92943514A0337D460CF5D@SW-EX-MBX01.diasemi.com> (raw) In-Reply-To: <20151110154434.GG12392@sirena.org.uk> On November 10, 2015 15:45, Mark Brown wrote: > > It's to detect the noise level on a mic and raise an event if the captured > > sound is above a specific threshold level. Apologies if that wasn't clear. > > > In the driver code I'm using KEY_VOICECOMMAND, and simulating a press and > > release of this key, to indicate to user-space. This seemed like the obvious > > choice for this feature to me, although I'd happily get your opinion on this. > > 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. > 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 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.
next prev parent reply other threads:[~2015-11-10 16:21 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-11-05 10:43 [PATCH 0/2] ASoC: Add support for DA7217 and DA7218 audio codecs Adam Thomson 2015-11-05 10:43 ` Adam Thomson 2015-11-05 10:43 ` [PATCH 1/2] ASoC: da7218: Add bindings documentation for DA7218 audio codec Adam Thomson 2015-11-05 10:43 ` Adam Thomson 2015-11-05 14:58 ` Mark Brown 2015-11-05 17:59 ` Opensource [Adam Thomson] 2015-11-05 17:59 ` Opensource [Adam Thomson] 2015-11-06 10:30 ` Mark Brown 2015-11-05 10:43 ` [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Adam Thomson 2015-11-05 10:43 ` Adam Thomson 2015-11-05 15:27 ` Mark Brown 2015-11-06 11:11 ` Opensource [Adam Thomson] 2015-11-06 11:11 ` Opensource [Adam Thomson] 2015-11-06 11:21 ` Mark Brown 2015-11-06 11:21 ` Mark Brown 2015-11-06 11:53 ` Opensource [Adam Thomson] 2015-11-06 11:53 ` Opensource [Adam Thomson] 2015-11-06 11:54 ` Mark Brown 2015-11-06 11:54 ` Mark Brown 2015-11-06 13:17 ` Opensource [Adam Thomson] 2015-11-06 13:17 ` Opensource [Adam Thomson] 2015-11-08 10:34 ` Mark Brown 2015-11-08 10:34 ` Mark Brown 2015-11-09 12:28 ` Opensource [Adam Thomson] 2015-11-09 12:28 ` Opensource [Adam Thomson] 2015-11-09 14:02 ` Mark Brown 2015-11-09 14:02 ` Mark Brown 2015-11-10 13:55 ` Opensource [Adam Thomson] 2015-11-10 13:55 ` Opensource [Adam Thomson] 2015-11-10 14:15 ` Mark Brown 2015-11-10 14:24 ` Opensource [Adam Thomson] 2015-11-10 14:24 ` Opensource [Adam Thomson] 2015-11-10 15:44 ` Mark Brown 2015-11-10 16:21 ` Opensource [Adam Thomson] [this message] 2015-11-10 16:21 ` Opensource [Adam Thomson] 2015-11-10 16:42 ` Mark Brown 2015-11-10 16:42 ` Mark Brown
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2E89032DDAA8B9408CB92943514A0337D460CF5D@SW-EX-MBX01.diasemi.com \ --to=adam.thomson.opensource@diasemi.com \ --cc=Support.Opensource@diasemi.com \ --cc=alsa-devel@alsa-project.org \ --cc=broonie@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=galak@codeaurora.org \ --cc=ijc+devicetree@hellion.org.uk \ --cc=lgirdwood@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=pawel.moll@arm.com \ --cc=perex@perex.cz \ --cc=robh+dt@kernel.org \ --cc=tiwai@suse.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.