On Tue, Nov 10, 2015 at 04:21:04PM +, 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
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
On Tue, Nov 10, 2015 at 02:24:13PM +, Opensource [Adam Thomson] wrote:
> On November 10, 2015 14:15, Mark Brown wrote:
> > So this *isn't* a normal mic detection feature? What's the userspace
> > interface for reporting then?
> By mic detection you thought this was to detect if a mic was
On November 10, 2015 14:15, Mark Brown wrote:
> > > 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 Tue, Nov 10, 2015 at 01:55:30PM +, Opensource [Adam Thomson] wrote:
> On November 9, 2015 14:02, Mark Brown wrote:
> > The general userspace expectation is that the detection is always active
> > and consistent rather than varying at runtime - runtime variability
> > might be a bit
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
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
On Tue, Nov 10, 2015 at 02:24:13PM +, Opensource [Adam Thomson] wrote:
> On November 10, 2015 14:15, Mark Brown wrote:
> > So this *isn't* a normal mic detection feature? What's the userspace
> > interface for reporting then?
> By mic detection you thought this was to detect if a mic was
On Tue, Nov 10, 2015 at 04:21:04PM +, 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
On Tue, Nov 10, 2015 at 01:55:30PM +, Opensource [Adam Thomson] wrote:
> On November 9, 2015 14:02, Mark Brown wrote:
> > The general userspace expectation is that the detection is always active
> > and consistent rather than varying at runtime - runtime variability
> > might be a bit
On November 10, 2015 14:15, Mark Brown wrote:
> > > 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 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
On Mon, Nov 09, 2015 at 12:28:39PM +, Opensource [Adam Thomson] wrote:
> On November 8, 2015 10:34, 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
On November 8, 2015 10:34, Mark Brown wrote:
> > > Hang on, is this just recording a DC value with the ADC and then looking
> > > at that?
>
> > The RMS of the Mic signal is taken and compared to the trigger level set. If
> > it's above that level then an IRQ is raised.
>
> What I'm trying to
On Mon, Nov 09, 2015 at 12:28:39PM +, Opensource [Adam Thomson] wrote:
> On November 8, 2015 10:34, 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
On November 8, 2015 10:34, Mark Brown wrote:
> > > Hang on, is this just recording a DC value with the ADC and then looking
> > > at that?
>
> > The RMS of the Mic signal is taken and compared to the trigger level set. If
> > it's above that level then an IRQ is raised.
>
> What I'm trying to
On Fri, Nov 06, 2015 at 01:17:28PM +, Opensource [Adam Thomson] wrote:
> On November 6, 2015 11:55, Mark Brown wrote:
> > Hang on, is this just recording a DC value with the ADC and then looking
> > at that?
> The RMS of the Mic signal is taken and compared to the trigger level set. If
>
On Fri, Nov 06, 2015 at 01:17:28PM +, Opensource [Adam Thomson] wrote:
> On November 6, 2015 11:55, Mark Brown wrote:
> > Hang on, is this just recording a DC value with the ADC and then looking
> > at that?
> The RMS of the Mic signal is taken and compared to the trigger level set. If
>
On November 6, 2015 11:55, Mark Brown wrote:
> > > > I can envisage in a system you may want to choose which capture
> > > > channels can
> > > > trigger level detection (if any), and this may change depending on the
> > > > use-case
> > > > at the time, so having it as a control makes sense to
On Fri, Nov 06, 2015 at 11:53:00AM +, Opensource [Adam Thomson] wrote:
> On November 6, 2015 11:22, Mark Brown wrote:
> > > I can envisage in a system you may want to choose which capture channels
> > > can
> > > trigger level detection (if any), and this may change depending on the
> > >
On November 6, 2015 11:22, Mark Brown wrote:
> > > > +static int da7218_mic_lvl_det_sw_put(struct snd_kcontrol *kcontrol,
> > > > +struct snd_ctl_elem_value
> > > > *ucontrol)
> > > > +{
>
> > > Why is this a user visible control?
>
> > I can envisage in a
On Fri, Nov 06, 2015 at 11:11:38AM +, Opensource [Adam Thomson] wrote:
> On November 5, 2015 15:28, Mark Brown wrote:
> > > +static int da7218_mic_lvl_det_sw_put(struct snd_kcontrol *kcontrol,
> > > + struct snd_ctl_elem_value *ucontrol)
> > > +{
> > Why is this
On November 5, 2015 15:28, Mark Brown wrote:
> > +/* ALC */
> > +static void da7218_alc_calib(struct snd_soc_codec *codec)
> > +{
> > + struct da7218_priv *da7218 = snd_soc_codec_get_drvdata(codec);
> > + u8 calib_ctrl;
> > + int i = 0;
> > + bool calibrated = false;
> > +
> > + /*
On November 5, 2015 15:28, Mark Brown wrote:
> > +/* ALC */
> > +static void da7218_alc_calib(struct snd_soc_codec *codec)
> > +{
> > + struct da7218_priv *da7218 = snd_soc_codec_get_drvdata(codec);
> > + u8 calib_ctrl;
> > + int i = 0;
> > + bool calibrated = false;
> > +
> > + /*
On November 6, 2015 11:22, Mark Brown wrote:
> > > > +static int da7218_mic_lvl_det_sw_put(struct snd_kcontrol *kcontrol,
> > > > +struct snd_ctl_elem_value
> > > > *ucontrol)
> > > > +{
>
> > > Why is this a user visible control?
>
> > I can envisage in a
On November 6, 2015 11:55, Mark Brown wrote:
> > > > I can envisage in a system you may want to choose which capture
> > > > channels can
> > > > trigger level detection (if any), and this may change depending on the
> > > > use-case
> > > > at the time, so having it as a control makes sense to
On Fri, Nov 06, 2015 at 11:53:00AM +, Opensource [Adam Thomson] wrote:
> On November 6, 2015 11:22, Mark Brown wrote:
> > > I can envisage in a system you may want to choose which capture channels
> > > can
> > > trigger level detection (if any), and this may change depending on the
> > >
On Fri, Nov 06, 2015 at 11:11:38AM +, Opensource [Adam Thomson] wrote:
> On November 5, 2015 15:28, Mark Brown wrote:
> > > +static int da7218_mic_lvl_det_sw_put(struct snd_kcontrol *kcontrol,
> > > + struct snd_ctl_elem_value *ucontrol)
> > > +{
> > Why is this
On Thu, Nov 05, 2015 at 10:43:19AM +, Adam Thomson wrote:
> +/* ALC */
> +static void da7218_alc_calib(struct snd_soc_codec *codec)
> +{
> + struct da7218_priv *da7218 = snd_soc_codec_get_drvdata(codec);
> + u8 calib_ctrl;
> + int i = 0;
> + bool calibrated = false;
> +
> +
On Thu, Nov 05, 2015 at 10:43:19AM +, Adam Thomson wrote:
> +/* ALC */
> +static void da7218_alc_calib(struct snd_soc_codec *codec)
> +{
> + struct da7218_priv *da7218 = snd_soc_codec_get_drvdata(codec);
> + u8 calib_ctrl;
> + int i = 0;
> + bool calibrated = false;
> +
> +
30 matches
Mail list logo
