On Tue, Sep 27, 2022 at 11:57:53AM +0800, Jason Zhu wrote:
> 
> 在 2022/9/26 23:33, Mark Brown 写道:
> > On Mon, Sep 26, 2022 at 09:52:34AM +0200, Pierre-Louis Bossart wrote:
> > > On 9/26/22 03:34, Jason Zhu wrote:
> > > > 在 2022/9/23 20:55, Mark Brown 写道:

> > > > > > The data can not be lost in this process. So we attach VAD & PDM
> > > > > > in the same card, then close the card and wake up VAD & PDM again
> > > > > > when the system is goto sleep. Like these code:

> > > > > This sounds like a very normal thing with a standard audio stream -
> > > > > other devices have similar VAD stuff without needing to open code access
> > > > > to the PCM operations?

> > > > At present, only VAD is handled in this way by Rockchip.

> > The point here is that other non-Rockchip devices do similar sounding
> > things?

> No.  Usually, the vad is integrated in codec, like rt5677, and is linked
> with DSP to
> handle its data. If DSP detects useful sound, send an irq to system to
> wakeup and
> record sound.  Others detect and analysis sound by VAD itself, like
> K32W041A.

What I mean here is that you're missing my point.  The deferring of full
wake word recognition to a secondary algorithm running somewhere else is
a pretty common design.

> > If this is something that's not uncommon that sounds like an even
> > stronger reason for not just randomly exporting the symbols and open
> > coding things in individual drivers outside of framework control.  What
> > are these other use cases, or is it other instances of the same thing?

> Maybe in this case: One PDM is used to record sound, and there is two way
> to move data. Use the VAD to move data to sram when system is sleep and
> use DMA to move data when sytem is alive. If we seperate this in two audio
> streams, we close the "PDM + VAD" audio stream firstly when system is alive
> and open "PDM + DMA" audio stream. This process maybe take long time
> that PDM FIFO will be full and lost some data. But we hope that data will
> not be lost in the whole proces. So these must be done in one audio
> stream.

I'd have exepected that any handover be done such that the low power
wake word stream is running concurrently with the main audio stream for
some period of time, possibly until the sync between the two has been
worked out, and that data would be being read out of the wake word
stream while the full stream is starting up.  As you say I'd expect that
otherwise you'll run into trouble with dropouts.  I don't see how doing
that handover would require that we export any symbols though, if there
is any kernel support needed it should be handled in the framework.