Open plbossart opened 1 year ago
e79b6343b89673212f9eec2efdab03a6b21617f7 is the first bad commit
commit e79b6343b89673212f9eec2efdab03a6b21617f7
Author: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
Date: Thu Apr 20 11:16:13 2023 +0200
host-zephyr: Fix glitches
Fixes glitches when host copier has different container size on
source and sink.
Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
src/audio/host-zephyr.c | 43 +++++++++++++++++++++++++------------------
@bardliao can you reproduce my bisect results?
@serhiy-katsyuba-intel @kv2019i FYI, I have no idea how a link configuration change might be impacted by host-dma changes, but git bisect won't lie.
e79b6343b896 is very old! Have you tried reverting it on a recent branch, does that also make a difference? There are some conflicts but they seem manageable.
but git bisect won't lie.
... except when test results are non-deterministic. Good you wrote: "Reproduction Rate: 100%"
@plbossart , https://github.com/thesofproject/sof/pull/7477 fixes the calculation of amount of bytes to copy from/to host DMA buffer when host copier does format conversion between 16 <--> 32 bit container size. If that commit triggers the issue, I'd suggest to check if buffers size is sufficient for the audio format. I guess, there is 16 to 32 bit container conversion in host-copier in your topology (otherwise the fix will have no effect) and so host-copier sink buffer size must be 384 bytes minimum for 1 ms period. If that buffer is smaller (or any other downstream buffer for 32-bit container) when the fix will make host-copier to get less data and playback will take more time.
Not sure how this is related to SoundWire frequency. Maybe besides changes to frequency also some changes to topology were introduced that modified either buffers size or audio format to 32-bit inside the pipeline?
@bardliao can you reproduce my bisect results?
@serhiy-katsyuba-intel @kv2019i FYI, I have no idea how a link configuration change might be impacted by host-dma changes, but git bisect won't lie.
Yes, I can reproduce the issue with the "host-zephyr: Fix glitches" commit and can't reproduce with the "228ecf57680ed12c9087bf6d2a02c1689936cedb topology2: hdmi-generic: Fix audio format for DAI copier" commit which is the commit right before "host-zephyr: Fix glitches".
@bardliao , do you have a dmesg log for the case when the issue is reproduced? It can show buffers size and formats.
@serhiy-katsyuba-intel the firmware buffers and formats are exactly the same between the working 9.6 and 12MHz case and the non-working 12.288MHz. The only thing that changes is that the link is a bit faster and the SoundWire frame shape is a bit different (64x8 instead of 50x10).
@bardliao , do you have a dmesg log for the case when the issue is reproduced? It can show buffers size and formats.
@serhiy-katsyuba-intel dmesg.txt
Due to the fact that at this point this bug, doesn't directly affect the current FW, lowering it to P3
Is the "Audio Cardinal clock" (whatever that is) never going to be used?
It's one of those things that are not needed until they are... using 12.288MHz gives a 64 rows x 8 columns, whereas 9.6 gives 50 rows x 8 columns. It's not a really significant difference until 32 bits are really required for each stream and bandwidth requirements exceed what the bus can deliver. It's still important but not urgent.
Describe the bug
When the SoundWire link clock is configured to 12.288 or 6.144 MHz (Audio Cardinal clock as source), the playback duration is 2x longer than normal
This does not happen with 12 or 6 MHz (Audio PLL as source) or with 9.6/4.8 MHz (Xtal as source).
To Reproduce Steps to reproduce the behavior: (e.g. list commands or actions used to reproduce the bug)
Reproduction Rate
100%
Expected behavior playback duration is correct
Impact
showstopper
Environment
This relies on a Linux kernel change https://github.com/thesofproject/linux/pull/4605 and can be seen on both MTL and LNL RVPs with RT711 on link 0
Screenshots or console output