Re: [PATCH 1/1] ASoC: soc-dai: export some symbols

[Jason Zhu <jason.zhu@rock-chips.com>]

在 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.