[keyonjie]

Add a state KPB_STATE_REALTIME for the realtime copy, and stop propagate
copying while at draining.

Signed-off-by: Keyon Jie yang.jie@linux.intel.com

[keyonjie]

SOFCI TEST

[keyonjie]

@xiulipan @DarrenxWang can you help check why On-device Test Failed:CFL_RVP_HDA:deployfail here?

[keyonjie]

@xiulipan @DarrenxWang now it passed, thanks.

[keyonjie]

@mrajwa @tlauda can you please help review this?

[wenqingfu]

what issue id is this PR associated with? @keyonjie

[jajanusz]

@mrajwa @tlauda please take a look at this

[keyonjie]

what issue id is this PR associated with? @keyonjie

No reported issue, only for kpb status cleanup, but I believe @mrajwa will have much more consequent PRs related to be submitted.

[tlauda]

@mrajwa @keyonjie Shouldn't we still copy the data to the end of keyphrase buffer during the draining phase? Otherwise we will miss the data captured between detection and end of draining.

[keyonjie]

@mrajwa @keyonjie Shouldn't we still copy the data to the end of keyphrase buffer during the draining phase? Otherwise we will miss the data captured between detection and end of draining.

This dropping is under our design now. about 30~50ms data.

[lbetlej]

@mrajwa @keyonjie Could you confirm that from functionality standpoint there will be no dropped data at KPB ? Data captured from mics after keyphrase is detected and during draining phase should be preserved by KPB until is transmitted to host.

[mrajwa]

@lbetlej, @tlauda, if your question is "will the history buffer remain intact during the draining event and after draining is done" then yest it will. If your question is "what will happen to the data which will be buffered during the draining and after that (the new data)" then no, it will be lost. We need to "rearm" KPB the whole system for consecutive buffering. Does it answer your question?

PS: please check the release branch, for newest version glk-012-stable-branch

[keyonjie]

@lbetlej @tlauda what are you really care about here? the data dropping during the draining, or the re-aiming of next detection? If it is the latter, we must design logic to support consecutive kwd firstly, e.g. while we are in draining or real-time copying, the 2nd keyphrase is detected, how should we handle to this 2nd detection?

From the driver side, what it does is only capturing data and pass them to the application.
If the application wants to reset the stream, it will send a trigger stop and reset, so we might need to introduce application developer for this kind of discussion: e.g. if the 2nd keyphrase detected, we might need to give up the previous data(including keyphrase + cmd), this need interaction with application, before we do the whole thing we do for the 1st iteration again.

[tlauda]

@keyonjie I worry about data dropping during the draining.

[tlauda]

@keyonjie Should we close this, since the similar change has been also submitted in #1462?

[keyonjie]

@keyonjie I worry about data dropping during the draining.

@tlauda dropping them(about 6~60ms right after detected) looks most simplest way to me, this data doesn't belong to draining(detected) neither key phrase nor real-time data(that we can handle/copy it in real time), we might need figure out how it could be handled, in current solution, this data is excluded.

[keyonjie]

@keyonjie Should we close this, since the similar change has been also submitted in #1462?

That's true, let @mrajwa decide it since he is "re-designing" this part. :-D

[tlauda]

Changes included in #1462.