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] Post Processing XRUN when playing multiple times on same topology #4104
Describe the bug
In any Post Processing test when trying to play 2 times or more on one topology (new streams are created, topology stays intact) SteamStall caused by XRUN occurs.
To Reproduce
Any python test from groups:
25_00_TestGenericProcessorSimplePlb
25_02_TestGenericProcessorCompMultiCorePlb
25_06_TestGenericProcessorPplMultiCorePlb
with parameters:
--playback_iterations=2
Reproduction Rate
100%
Environment
Name of the platform(s) on which the bug is observed.
if you start cplay after 2 or more seconds everything works well.
I assume that on full stack if pipeline is not used for certain amount of time it's being destroyed and then created again if needed.
I run quick test and when creating/deleting topology each iteration bug doesn't occurs. So all is fine when Processor Component is being destroyed after playback.
#4263 works with test that @mrajwa required (25_01_TestGenericProcessorRuntimeConfig with all parameters). All iteration pass (--playback_iterations=20).
Other problem occurred:
Glitch in test: 25_02_TestGenericProcessorCompMultiCorePlb48000Hz16b16b4ch reproduction rate: 2/20
Glitch in test: 25_06_TestGenericProcessorPplMultiCorePlb48000Hz16b16b4ch reproduction rate: 1/20
@mrajwa it is impossible to verify if it happens without this PR (please, see the bug description).
All Post Processing tests passed in the very first iteration (with this PR and without)
I run all Post Processing tests with parameters:
--topology_iterations=6
--playback_iterations=6
and found glitches in tests:
@kkarask as the glitches are another issue, can you verify if the XRUN issue original reported here is fixed by #4263 ? e.g. without #4263 does the XRUN issue happen? With PR #4263 applied, does the XRUN issue disappear?
Activity
lgirdwood commentedon May 10, 2021
@dbaluta fyi, have you seen this on your side ? I'm wondering here if we are not correctly tearing down the codec adapter pipeline at stream close.
lgirdwood commentedon May 10, 2021
lgirdwood commentedon May 10, 2021
Linked to #3966 ?
dbaluta commentedon May 10, 2021
@zrombel I actually did notice that:
I plan to investigate this. Initially I thought that might have something to do with DRAIN which is not yet implemented.
zrombel commentedon May 10, 2021
I assume that on full stack if pipeline is not used for certain amount of time it's being destroyed and then created again if needed.
I run quick test and when creating/deleting topology each iteration bug doesn't occurs. So all is fine when Processor Component is being destroyed after playback.
dbaluta commentedon May 10, 2021
@zrombel yes, this happens because of PM runtime suspend.
mrajwa commentedon May 10, 2021
@zrombel can you try this -> #4162
zrombel commentedon May 11, 2021
Unfortunately PR #4162 doesn't fix this bug.
Logs from test with 2x playback iterations:
MRajwa_PR4162_25_00_TestGenericProcessorSimplePlb48000Hz32b32b2ch_XRUN.zip
lgirdwood commentedon May 18, 2021
@dbaluta any update from your side here ?
4 remaining items
kkarask commentedon Jun 2, 2021
I'm working on it. This requires a change in test.
lgirdwood commentedon Jun 3, 2021
@kkarask thanks, let us know when results are available. @keyonjie @mengdonglin
keyonjie commentedon Jun 9, 2021
@kkarask ping for update. We are gonna to freeze the 1.8 final, if this issue still exist, we will have to push it out for 1.9.
kkarask commentedon Jun 9, 2021
#4263 works with test that @mrajwa required (25_01_TestGenericProcessorRuntimeConfig with all parameters). All iteration pass (--playback_iterations=20).
Other problem occurred:

Glitch in test: 25_02_TestGenericProcessorCompMultiCorePlb48000Hz16b16b4ch reproduction rate: 2/20
Glitch in test: 25_06_TestGenericProcessorPplMultiCorePlb48000Hz16b16b4ch reproduction rate: 1/20

mrajwa commentedon Jun 9, 2021
Needs to verify:
kkarask commentedon Jun 10, 2021
@mrajwa it is impossible to verify if it happens without this PR (please, see the bug description).
All Post Processing tests passed in the very first iteration (with this PR and without)
I run all Post Processing tests with parameters:
--topology_iterations=6
--playback_iterations=6
and found glitches in tests:
25_00_TestGenericProcessorSimplePlb48000Hz16b16b8ch
glitch occurs:
Topology=5, iter=2
25_02_TestGenericProcessorCompMultiCorePlb48000Hz16b16b4ch
In each topology glitches occur in two iterations (iteration 2 and 3)
25_02_TestGenericProcessorCompMultiCorePlb48000Hz16b16b8ch
glitches occur:
Topology=0, iter=2
Topology=1, iter=2
Topology=5, iter=2
25_06_TestGenericProcessorPplMultiCorePlb48000Hz16b16b4ch
glitches occur:
Topology=1, iter=2
Topology=2, iter=2
Topology=4, iter=2
Topology=5, iter=2
All glitches are at the beginning of the wav file.
keyonjie commentedon Jun 10, 2021
@kkarask as the glitches are another issue, can you verify if the XRUN issue original reported here is fixed by #4263 ? e.g. without #4263 does the XRUN issue happen? With PR #4263 applied, does the XRUN issue disappear?
kkarask commentedon Jun 11, 2021
@keyonjie yes, #4263 fixed the original issue.
keyonjie commentedon Jun 11, 2021
Thanks, then let's close this once #4263 merged and file a new one for the glitches issue.
keyonjie commentedon Jun 16, 2021
1.8 is already froze, postpone this to 1.9
abonislawski commentedon Jan 25, 2022
@kkarask is the glitch problem still valid? If yes, please open a new issue