LNL NOCODEC alsa-bat playback failure #9123

Activity

1. plbossart

   added

   LNLApplies to Lunar Lake platformApplies to Lunar Lake platform

   on Apr 30, 2024
2. plbossart commented on May 13, 2024

   

   plbossart

   on May 13, 2024

   MemberAuthor

   More actions

   another one: https://sof-ci.01.org/sofpr/PR9119/build4654/devicetest/index.html?model=LNLM_RVP_NOCODEC&testcase=check-alsabat-headset-playback-599

   It's not the same frequency as previously....
3. plbossart commented on May 13, 2024

   

   plbossart

   on May 13, 2024

   Last edited by plbossart

   MemberAuthor

   More actions

   https://sof-ci.01.org/linuxpr/PR4899/build2589/devicetest/index.html?model=LNLM_RVP_NOCODEC&testcase=check-alsabat-headset-playback-821 has an xrun reported by userspace but nothing in the firmware trace.

   https://sof-ci.01.org/sofpr/PR9119/build4654/devicetest/index.html?model=LNLM_RVP_NOCODEC&testcase=check-alsabat-headset-playback-599 has no xrun reported by userspace, but the trace has tons of

   [ 4138.879225] <inf> host_comp: host_get_copy_bytes_normal: comp:0 0x4 no bytes to copy, available samples: 0, free_samples: 192
   [ 4138.883155] <wrn> dai_comp: dai_common_copy: comp:1 0x10004 dai_common_copy(): Copy_bytes 192 + avail bytes 56 < period bytes 384, possible glitch
   [ 4138.891155] <wrn> dai_comp: dai_common_copy: comp:1 0x10004 dai_common_copy(): Copy_bytes 192 + avail bytes 56 < period bytes 384, possible glitch
   [ 4138.892155] <wrn> dai_comp: dai_common_copy: comp:1 0x10004 dai_common_copy(): Copy_bytes 192 + avail bytes 8 < period bytes 384, possible glitch
   
4. plbossart commented on May 13, 2024

   

   plbossart

   on May 13, 2024

   MemberAuthor

   More actions

   @ujfalusi @kv2019i what do you think of this one? The topology is supposedly the same as on MTL, so the DMA/firmware changes are probably the reason for these test failures.
5. kv2019i commented on May 13, 2024

   

   kv2019i

   on May 13, 2024

   Collaborator

   More actions

   @plbossart Both above test runs have "Broken pipe":

   2024-04-30 18:02:26 UTC [REMOTE_COMMAND] alsabat -Phw:sofnocodec,0 --standalone -n 240000 -r 48000 -c 2 -f S16_LE -F 821 -k 2.1
   2024-04-30 18:02:27 UTC [REMOTE_COMMAND] alsabat -Chw:sofnocodec,0 -c 2 -r 48000 -f S16_LE -F 821 -k 2.1
   Overrun: Broken pipe(-32)
   

   I think this is related. The capture audio file has flawless audio for first 33000 samples and then it breaks down.
6. marc-hb commented on May 14, 2024

   

   marc-hb

   on May 14, 2024

   Last edited by marc-hb

   Collaborator

   More actions

   Another, very recent alsabat regression, this time on capture and MTLP_RVP_HDA ba-mtlp-rvp-hda-03. Yet another, different issue?

   If different then it would be a very strange timing coincidence because both test cases have been very consistently passing over the last few weeks.

   https://sof-ci.01.org/softestpr/PR1193/build422/devicetest/index.html?model=MTLP_RVP_HDA&testcase=check-alsabat-headset-capture-997
7. plbossart

   transferred this issue fromthesofproject/linuxon May 14, 2024
8. marc-hb

   changed the title [-]LNL NOCODEC alsa-bat failure[/-] [+]LNL NOCODEC alsa-bat playback failure[/+] on May 17, 2024
9. plbossart commented on May 20, 2024

   

   plbossart

   on May 20, 2024

   MemberAuthor

   More actions

   Now we have a broken test with NOCODEC alsa-bat capture

   https://sof-ci.01.org/linuxpr/PR5007/build3042/devicetest/index.html?model=LNLM_RVP_NOCODEC&testcase=check-alsabat-headset-capture-821

   I must admit I don't know if what the difference is between alsa-bat-headset-playback and alsa-bat-headset-capture, we need to play and capture on the same devices and test the same loopback

   playback:
   https://sof-ci.01.org/linuxpr/PR5007/build3042/devicetest/index.html?model=LNLM_RVP_NOCODEC&testcase=check-alsabat-headset-playback-821
   2024-05-20 19:59:03 UTC [REMOTE_COMMAND] alsabat -Phw:sofnocodec,0 --standalone -n 240000 -r 48000 -c 2 -f S16_LE -F 821 -k 2.1
   2024-05-20 19:59:04 UTC [REMOTE_COMMAND] alsabat -Chw:sofnocodec,0 -c 2 -r 48000 -f S16_LE -F 821 -k 2.1

   capture:
   https://sof-ci.01.org/linuxpr/PR5007/build3042/devicetest/index.html?model=LNLM_RVP_NOCODEC&testcase=check-alsabat-headset-capture-821
   2024-05-20 20:00:49 UTC [REMOTE_COMMAND] alsabat -Phw:sofnocodec,0 --standalone -n 240000 -r 48000 -c 2 -f S16_LE -F 821 -k 2.1
   2024-05-20 20:00:51 UTC [REMOTE_COMMAND] alsabat -Chw:sofnocodec,0 -c 2 -r 48000 -f S16_LE -F 821 -k 2.1

   Looks the same to me? What am I missing @fredoh9 @marc-hb @kv2019i ?
10. abonislawski

    added

    P1Blocker bugs or important featuresBlocker bugs or important features

    on May 21, 2024
11. kv2019i commented on May 21, 2024

    

    kv2019i

    on May 21, 2024

    Collaborator

    More actions

    @plbossart At least in the capture case, there is again glitches in capture audio. In specific case of
    https://sof-ci.01.org/linuxpr/PR5007/build3042/devicetest/index.html?model=LNLM_RVP_NOCODEC&testcase=check-alsabat-headset-playback-821
    ... it's smaller than before and seems to be exactly one 1ms tick of audio missing:

    
12. marc-hb commented on May 22, 2024

    

    marc-hb

    on May 22, 2024

    Collaborator

    More actions

    Looks the same to me? What am I missing @fredoh9 @marc-hb @kv2019i ?

    @fredoh9 just explained this to me: NOCODEC is special.

    Outside NOCODEC:

    • alsabat-playback: SOF playback, USB capture
    • alsabat-capture: USB playback, SOF capture

    NOCODEC is special, it has no USB. So:

    • SOF playback, SOF capture.

    So both tests do more or less the same thing on NOCODEC.
13. plbossart commented on May 22, 2024

    

    plbossart

    on May 22, 2024

    MemberAuthor

    More actions

    Right, so can we skip the capture part to avoid unnecessary confusions?
14. lgirdwood commented on May 22, 2024

    

    lgirdwood

    on May 22, 2024

    Member

    More actions

    ... it's smaller than before and seems to be exactly one 1ms tick of audio missing:

    and its also suspiciously close to 0.5 seconds of audio. 0.5 second USB audio buffer size ???
15. plbossart commented on May 22, 2024

    

    plbossart

    on May 22, 2024

    MemberAuthor

    More actions

    ... it's smaller than before and seems to be exactly one 1ms tick of audio missing:

    and its also suspiciously close to 0.5 seconds of audio. 0.5 second USB audio buffer size ???

    There's no USB involved in Nocodec mode, it's an SSP loopback.
16. 45 remaining items

    Load more
17. serhiy-katsyuba-intel

    added a commit that references this issue on Jul 15, 2024

    copier: Add bind function to configure sink buffers params

    ...

    This issue will close once commit 5c72569 is merged into the 'main' branch.

    5c72569
18. marc-hb commented on Jul 15, 2024

    

    marc-hb

    on Jul 15, 2024

    Collaborator

    More actions

    To be closed after one round of daily tests.
19. marc-hb

    reopened this on Jul 15, 2024
20. eddy1021

    added a commit that references this issue on Jul 15, 2024

    copier: Add bind function to configure sink buffers params

    ...

    This issue will close once commit 1db1b5e is merged into the 'main' branch.

    1db1b5e
21. marc-hb

    closed this as completedon Jul 18, 2024
22. marc-hb commented on Jul 18, 2024

    

    marc-hb

    on Jul 18, 2024

    Collaborator

    More actions

    This just failed again:
    https://sof-ci.01.org/sofpr/PR9313/build6571/devicetest/index.html?model=LNLM_RVP_NOCODEC&testcase=check-alsabat-nocodec-32bits-997
23. marc-hb

    reopened this on Jul 18, 2024
24. softwarecki

    removed their assignment

    on Jul 19, 2024
25. softwarecki commented on Jul 19, 2024

    

    softwarecki

    on Jul 19, 2024

    Last edited by softwarecki

    Collaborator

    More actions

    @marc-hb I don't see any glitches in the attached wave file
    

    only the peak at 999 Hz is visible in fft
    

    I think this is a different issue than the one I fixed.
26. wszypelt commented on Aug 23, 2024

    

    wszypelt

    on Aug 23, 2024

    More actions

    @marc-hb Could you please take a look at the @softwarecki respone?
27. lgirdwood commented on Aug 23, 2024

    

    lgirdwood

    on Aug 23, 2024

    Member

    More actions

    @ssavati @fredoh9 do we have the non USB loopback connectors enabled yet ?
28. marc-hb commented on Aug 23, 2024

    

    marc-hb

    on Aug 23, 2024

    Last edited by marc-hb

    Collaborator

    More actions

    I don't see any glitches in the attached wave file

    I don't know anything about the details sorry but I remember that in the past every time a "human eye" and alsabat disagreed, alsabat won eventually. I have no idea what caused this particular failure: it could be a LNL-specific USB bug, or a LNL-specific audio bug, a bug in sof-test or even something else but all the evidence so far has shown alsabat itself to be the least suspect.
29. fredoh9 commented on Aug 24, 2024

    

    fredoh9

    on Aug 24, 2024

    Contributor

    More actions

    @ssavati @fredoh9 do we have the non USB loopback connectors enabled yet ?

    I haven't purchased the loopback cables yet.
30. kv2019i commented on Sep 9, 2024

    

    kv2019i

    on Sep 9, 2024

    Collaborator

    More actions

    Reviewing a week worth of daily test plans with this configurationg (starting 2024-09-02), this test is passing all the time. It is likely zephyrproject-rtos/zephyr#77805 fix was responsible for the occasional 1ms glitches seen in this test and those are now gone. There is one failure left in the alsa-bat-capture test, I'll file a separate bug to track that.
31. kv2019i

    closed this as completedon Sep 9, 2024