[BUG] SSP TX starts with a ~4.2ms delay

[plbossart]

Describe the bug

While capturing the SSP output on an Up2 board, I can see with a Logic Pro grab that the data is delayed by 4.2ms

That's a rather large undocumented delta which didn't exist in the past.

To Reproduce

use the nocodec mode on Up2
aplay -Dhw:0,5 -c2 -r48000 -f SLE_16 aa_left.pcm

Reproduction Rate

100%

Expected behavior

No delay or small delay.

Impact

This may impact latency requirements on e.g. Google platforms

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • Kernel: 0e1e5072818cfd37c80010d2889f629ccb74c7ca
   • SOF: 8ed7888
2. Name of the topology file
   • Topology: sof-apl-nocodec.tplg
3. Name of the platform(s) on which the bug is observed.
   • Platform: APL Up2

Screenshots or console output

[keyonjie]

those 4ms could be 0s samples/data?

[plbossart]

those 4ms could be 0s samples/data?

my current hypothesis is that we have too many periods in the pipeline and have lost the ability to 'pre-roll' the pipeline.
So yes IMHO those 4 ms are related to some delay in the pipelines and a volume ramp.

[lgirdwood]

those 4ms could be 0s samples/data?

my current hypothesis is that we have too many periods in the pipeline and have lost the ability to 'pre-roll' the pipeline.
So yes IMHO those 4 ms are related to some delay in the pipelines and a volume ramp.

Ack, that's what I'm thinking too - fwiw, we did increase the number of DMA periods to 3 to deal with a HW issue.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.