You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG][APL][KD] Detection signal data a the beginning of drained data #2270
Describe the bug
BUG found on APL platform in Keyword Detection test incorporating DMIC interface. Test plays 6 second wave file on dmic injector where 3 s is silent and 3 s contain sine signal. When Dummy component detects sine signal on DMIC interface it triggers KPB component to drain history buffer and continue playing realtime data. Recorded wave file should contain ~2.1 s of silence and 3 s of sine signal but at the begging of file there is a short sine signal of exactly 20 ms length (320 samples).
@lgirdwood DMIC starts with filters muted but there's possibility the FIFOs could contain old samples when started. I'll do some checks with my APL board.
Also to be safe the KPB should reject any positive detections for the first 500 ms or so after start. As seen in HDA capture many codecs output some noise in the beginning.
@singalsu I was suspecting the same about DMIC containing some old data but in my opinion is not the issue. First of all detection is triggered in right moment - after 3s of playback, if there was some data in DMIC FIFO detection would happen at the very beginning of playback. Second I've modified test so the sine signal fade over time, but data at the beginning still have full amplitude just like data from detection moment. So i my opinion this is a short mismatch between realtime and drain data somewhere in KPB.
@singalsu@zrombel are we sure we have cleared all buffers prior to DMIC trigger start ? @singalsu how big is the DMIC FIFO ? does it need cleared prior to start ?
@lgirdwood is there a way to explicitly clear buffers? This issue can be reproduced on first iteration, right after ADSP power on and in that case i thing that buffers are empty.
@zrombel, ok we know what happens. Can you in test change history_depth (the amount of data host requested from history buffer) from 2,1 seconds to 2 seconds? It looks like we have a delay on FW side and new data overwrite oldest data in history buffer.
Activity
lgirdwood commentedon Jan 9, 2020
@singalsu any inputs ?
singalsu commentedon Jan 9, 2020
@lgirdwood DMIC starts with filters muted but there's possibility the FIFOs could contain old samples when started. I'll do some checks with my APL board.
singalsu commentedon Jan 9, 2020
Also to be safe the KPB should reject any positive detections for the first 500 ms or so after start. As seen in HDA capture many codecs output some noise in the beginning.
zrombel commentedon Jan 10, 2020
@singalsu I was suspecting the same about DMIC containing some old data but in my opinion is not the issue. First of all detection is triggered in right moment - after 3s of playback, if there was some data in DMIC FIFO detection would happen at the very beginning of playback. Second I've modified test so the sine signal fade over time, but data at the beginning still have full amplitude just like data from detection moment. So i my opinion this is a short mismatch between realtime and drain data somewhere in KPB.
lgirdwood commentedon Jan 10, 2020
@singalsu @zrombel are we sure we have cleared all buffers prior to DMIC trigger start ?
@singalsu how big is the DMIC FIFO ? does it need cleared prior to start ?
zrombel commentedon Jan 10, 2020
@lgirdwood is there a way to explicitly clear buffers? This issue can be reproduced on first iteration, right after ADSP power on and in that case i thing that buffers are empty.
lgirdwood commentedon Jan 10, 2020
@zrombel pipeline should clear buffer before trigger start. If in doubt check with @tlauda
mrajwa commentedon Jan 27, 2020
@zrombel, can you please retest with this patch #2329
Thanks
zrombel commentedon Jan 29, 2020
PR #2329 does not fix this bug, Further more I found that this bug is also reproducible with SSP interface, so it's not only DMIC bug.
mrajwa commentedon Jan 29, 2020
@zrombel, ok we know what happens. Can you in test change history_depth (the amount of data host requested from history buffer) from 2,1 seconds to 2 seconds? It looks like we have a delay on FW side and new data overwrite oldest data in history buffer.
zrombel commentedon Feb 3, 2020
After validating with PR #2343 on APL platform bug no longer can be found. PR #2343 is fixing it.
lgirdwood commentedon Feb 20, 2020
@mrajwa any update on the Prs ? Is this blocking on @lbetlej returning ?
mrajwa commentedon Feb 21, 2020
@lgirdwood yes it's my responsibility, I will submit PR for soon.
slawblauciak commentedon Mar 31, 2020
@mrajwa any updates on this issue?
mrajwa commentedon Apr 1, 2020
@slawblauciak @zrombel the fix should be covered by this PR #2688
mrajwa commentedon Apr 7, 2020
Problem no longer reproducible after PR #2688, therefore I am closing this issue.