Re: [RFC 2/2] ASoC: Add MICFIL SoC Digital Audio Interface driver.

[Daniel Baluta <daniel.baluta@gmail.com>]

On Fri, Dec 14, 2018 at 10:09 PM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
>
> 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.

Reviving this discussion about VAD. Do you have any draft patches for
the interface to send events to user space?

We are now trying to upstream VAD for PDM and we are looking
at all our options.

thanks,
Daniel.