在 2022/9/28 19:52, Mark Brown 写道:
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.
Thank you very much. I will think about how to support it in the framework.
