[alsa-devel] [RFC 2/2] ASoC: Add MICFIL SoC Digital Audio Interface driver.

[Pierre-Louis Bossart]

On 12/12/18 12:14 PM, Mark Brown wrote:
>> +static irqreturn_t voice_detected_fn(int irq, void *devid)
>> +{
>> +	struct fsl_micfil *micfil = (struct fsl_micfil *)devid;
>> +	struct device *dev = &micfil->pdev->dev;
>> +	int ret;
>> +
>> +	/* disable hwvad */
>> +	ret = disable_hwvad(dev, true);
>> +	if (ret)
>> +		dev_err(dev, "Failed to disable HWVAD module\n");
>> +
>> +	/* notify userspace that voice was detected */
>> +	kobject_uevent_env(&dev->kobj, KOBJ_CHANGE, envp);
>> +
>> +	return IRQ_HANDLED;
>> +}
> So, this looks like it's intended to be used for keyword detection type
> applications (though without the offload DSP that those tend to have).
> What the other implementations I've seen have ended up doing is using a
> compressed audio stream to return the audio data to userspace, allowing
> the audion stream to be paused when no audio is detected.  Your approach
> here is a bit more manual and may be more sensible for systems without
> the offload DSP however the decision to go outside ALSA and use a
> kobject needs to be thought about a bit, we'd want to ensure that
> there's a standard way of handling hardware like this so applications
> can work as consistently as possible with them.

There's no mention of any buffer so it's likely plain vanilla VAD here. 
We've seen two choices to warn userspace of a acoustic event, either use 
a uevent or a kcontrol. I believe we ended-up chosing the latter on the 
Intel side in the past and that was also the plan for SOF.

In terms of configurations for the PDM we have completely different 
settings since we pass explicit coefficients while this solution passes 
qualifiers (cut-off, quality, etc), not sure if there is any point in 
trying to unify those parameters.