[BUG] Baytrail/CherryTrail: samples are not played in correct order

[plbossart]

Describe the bug

When playing samples that are incremented by one from a sample to the other, the output shows discontinuities of 96 samples, see
baytrail.xlsx
. With regular sine waves this has the net effect of adding noise.

This clearly points to bad buffer/pointer management or scheduling issues.

To Reproduce

Configure Minnowboard, use kernel topic/sof-dev and firmware v1.3-rc
connect LogicPro on SSP pins (bclk, fs, dac)
unzip and play file
cnt_1024_left.pcm.gz
aplay -Dhw:1,0 -c2 -r48000 -f dat cnt_1024_left.pcm
grab results with LogicPro and check the decoded values (should be similar to excel sheet provided above)

Expected behavior

samples are expected to be played in order, with wrap-around at 1024

Impact

showstopper

Environment

1. Branch name and commit hash of 3 repositories: sof (firmware), linux (kernel driver) and soft (tools & topology).

kernel f3adfd6
firmware eac4a73
2) Name of the topology file

sof-byt-nocodec.tplg (or any byt topology, doesn't matter)

3. Name of the platform(s) on which the bug is observed.

All Baytrail and cherrytrail platforms. The measurements are only seen when the connector is exposed, e.g. on Minnowboard.

4. Reproducibility Rate. 100%

[lgirdwood]

@mengdonglin @RanderWang I'm sure this is dw-dma DMA buffer R/W pointer related. The DMA on BYT does not support HW LLI mode and LLI must be programmed via SW. There have also been some recent commits to the DMA driver that should be bisected.

The issue here is that the DMA HW read period (data that is be sent to SSP) is being written by the FW pipeline at the same time. i.e. we are reading and writing the same period at the same time. Some trace should show this. This is obviously working in HW LLI mode for non BYT platforms.

[tlauda]

@ranj063 @xiulipan @lgirdwood What has changed since issue #1107 has been fixed? Are you saying there is another regression? The only problem with noise I was aware of was problem with SRC #1161.

[juimonen]

@tlauda @lgirdwood I did some bisecting and for me the problems start way back:
so this is minnowboard + rt5651 (and rt5651 topology, sof master cbd3e07)

1. 22e3cf9 works for me I can play audio and its clean.
2. 9a6a38a starts problems, this commit doesn't work at all
3. 407be96 onward until HEAD I can play but the sound is metallic.

[lgirdwood]

@tlauda not sure but CI was reporting false success.
@juimonen I've ran into this before hence I know the root cause. Can you check the DMA and it's source component R/W pointers as they are both using the same period for IO as explained above.

[xiulipan]

@tlauda @lgirdwood @juimonen
Confirmed with the today's daily build binary. With pause/resume the noise can be randomly recover.
It should be like what @lgirdwood have said

I'm sure this is dw-dma DMA buffer R/W pointer related. The DMA on BYT does not support HW LLI mode and LLI must be programmed via SW. There have also been some recent commits to the DMA driver that should be bisected.

The issue here is that the DMA HW read period (data that is be sent to SSP) is being written by the FW pipeline at the same time. i.e. we are reading and writing the same period at the same time. Some trace should show this. This is obviously working in HW LLI mode for non BYT platforms.

And we have fixed similar issue once. I think this maybe caused by the recent change to the pipeline.

But as 9a6a38a is something related to the mixer component. I will try to use some pass through pipeline to check if it is related to the mixer component first.

[juimonen]

@xiulipan 9a6a38a is the first in series of pipeline changes for variable frame size and I don't think the commits work individually. So I had to go up until 407be96 to get the pipeline even working.

[ranj063]

@juimonen to rule out the mixer as a suspect, can you try a simple host->vol->dai pipeline on BYT?