Skip to content

[BUG] Post Processing XRUN when playing multiple times on same topology #4104

Closed

Description

@zrombel

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.

Topology

+----------------------------------------------+
| +------+  +---+  +-------+  +---+  +-------+ |
| | Host +->+Buf+->+GenProc+->+Buf+->+SSP Dai+---+
| +------+  +---+  +-------+  +---+  +-------+ | |
+----------------------------------------------+ |
                                                 |
+----------------------------+                   |
| +------+  +---+  +-------+ |                   |
| | Host +<-+Buf+<-+SSP Dai+<--------------------+
| +------+  +---+  +-------+ |
+----------------------------+

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

  1. Name of the platform(s) on which the bug is observed.
    • Platform: TGL B0 RVP
  2. Firmware branch name and commit
  3. Python tests branch name and commit
    • Branch: master
    • Hash: 825533f4e0d3ff5e2425abb50e9785916d7d1044

Logs
25_00_TestGenericProcessorSimplePlb_StreamStall.zip

Activity

  1. added this to the v1.8 milestone on Apr 27, 2021
  2. lgirdwood commented on May 10, 2021

    @lgirdwood
    Member

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

  3. lgirdwood commented on May 10, 2021

    @lgirdwood
    Member
    [  5628978.880208] (       12.760417) c0 ssp-dai      1.0   /drivers/intel/ssp/ssp.c:843  ssp_trigger() cmd 1
    [  5628988.880208] (       10.000000) c0 ssp-dai      1.0   /drivers/intel/ssp/ssp.c:631  ssp_pre_start()
    [  5628998.281250] (        9.401042) c0 ssp-dai      1.0   /drivers/intel/ssp/ssp.c:760  ssp_start()
    [  5629055.442708] (       57.161457) c0 ll-schedule        ./schedule/ll_schedule.c:403  task add 0xbe0a0100 0x1fffa4e0U
    [  5629063.984375] (        8.541667) c0 ll-schedule        ./schedule/ll_schedule.c:407  task params pri 0 flags 0 start 0 period 1000
    [  5629076.510417] (       12.526042) c0 ll-schedule        ./schedule/ll_schedule.c:313  new added task->start 216160631 at 216156342
    [  5629084.921875] (        8.411458) c0 ll-schedule        ./schedule/ll_schedule.c:316  num_tasks 4 total_num_tasks 4
    [  5630249.322917] (     1164.401001) c0 codec_adapter 1.0   ......../codec/cadence.c:429  ERROR cadence_codec_process() error ffff80c4: processing failed
    [  5630260.208333] (       10.885417) c0 codec_adapter 1.0   ......../codec/generic.c:285  ERROR codec_prepare() error -32572: codec process failed for codec_id cade0101
    [  5630271.093750] (       10.885417) c0 codec_adapter 1.0   ......../codec_adapter.c:417  ERROR codec_adapter_copy() error ffff80c4: lib processing failed
    [  5630282.578125] (       11.484375) c0 pipe         1.5   ....../pipeline-stream.c:168  ERROR pipeline_copy(): ret = -32572, start->comp.id = 2, dir = 1
    [  5630294.739583] (       12.161458) c0 pipe         1.5   ..../pipeline-schedule.c:63   ERROR pipeline_task(): xrun recover failed! pipeline will be stopped!
    [  5630305.911458] (       11.171875) c0 ll-schedule        ./schedule/ll_schedule.c:127  task complete 0xbe0a0100 0x1fffa4e0U
    
  4. lgirdwood commented on May 10, 2021

    @lgirdwood
    Member

    Linked to #3966 ?

  5. dbaluta commented on May 10, 2021

    @dbaluta
    Collaborator

    @zrombel I actually did notice that:

    • cplay works fine at first run
    • cplay gets blocked waiting for DSP to consume the frames if you start the second cplay quick enough (1-2seconds).
    • if you start cplay after 2 or more seconds everything works well.

    I plan to investigate this. Initially I thought that might have something to do with DRAIN which is not yet implemented.

  6. zrombel commented on May 10, 2021

    @zrombel
    Author

    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.

  7. dbaluta commented on May 10, 2021

    @dbaluta
    Collaborator

    @zrombel yes, this happens because of PM runtime suspend.

  8. mrajwa commented on May 10, 2021

    @mrajwa
    Contributor

    @zrombel can you try this -> #4162

  9. zrombel commented on May 11, 2021

    @zrombel
    Author

    Unfortunately PR #4162 doesn't fix this bug.
    Logs from test with 2x playback iterations:
    MRajwa_PR4162_25_00_TestGenericProcessorSimplePlb48000Hz32b32b2ch_XRUN.zip

  10. lgirdwood commented on May 18, 2021

    @lgirdwood
    Member

    @dbaluta any update from your side here ?

  11. 4 remaining items

  12. kkarask commented on Jun 2, 2021

    @kkarask

    I'm working on it. This requires a change in test.

  13. lgirdwood commented on Jun 3, 2021

    @lgirdwood
    Member

    @kkarask thanks, let us know when results are available. @keyonjie @mengdonglin

  14. keyonjie commented on Jun 9, 2021

    @keyonjie
    Contributor

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

  15. kkarask commented on Jun 9, 2021

    @kkarask

    #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
    image

    Glitch in test: 25_06_TestGenericProcessorPplMultiCorePlb48000Hz16b16b4ch reproduction rate: 1/20
    image

  16. mrajwa commented on Jun 9, 2021

    @mrajwa
    Contributor

    Needs to verify:

    • if it happens without this PR (main branch)
    • if it happens in playback iterations mode or in topology iterations as well
    • if it happens in the very fist iteration
  17. kkarask commented on Jun 10, 2021

    @kkarask

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

  18. keyonjie commented on Jun 10, 2021

    @keyonjie
    Contributor

    @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?

  19. kkarask commented on Jun 11, 2021

    @kkarask

    @keyonjie yes, #4263 fixed the original issue.

  20. keyonjie commented on Jun 11, 2021

    @keyonjie
    Contributor

    @keyonjie yes, #4263 fixed the original issue.

    Thanks, then let's close this once #4263 merged and file a new one for the glitches issue.

  21. keyonjie commented on Jun 16, 2021

    @keyonjie
    Contributor

    1.8 is already froze, postpone this to 1.9

  22. modified the milestones: v1.8, v1.9 on Jun 16, 2021
  23. abonislawski commented on Jan 25, 2022

    @abonislawski
    Member

    @kkarask is the glitch problem still valid? If yes, please open a new issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P1Blocker bugs or important featuresPost ProcessingTGLApplies to Tiger LakebugSomething isn't working as expecteddiagnostic driverSlim driver / diagnostic driver issue

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions