[BUG][RPL][CHROMEOS] alsa_conformance_test fails for test rates

[Vamshigopal]

Describe the bug
Run alsa_conformance_test --test_suites test_rates to check the estimated rates are same as what it set.

More infomation on this test
https://chromium.googlesource.com/chromiumos/platform/audiotest/+/refs/heads/master/alsa_conformance_test.md#Stability-of-rate

To Reproduce
alsa_conformance_test.py -P hw:0,0 --test-suites test_rates --merge-thld-size 480

Reproduction Rate
100%

Expected behavior
alsa_conformance_test.py is a "standard" test that run on all previous platforms.

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).

   • Kernel: https://chromium.googlesource.com/a/chromiumos/third_party/kernel/+/refs/heads/chromeos-5.15
   • SOF: https://github.com/thesofproject/sof/tree/cavs2.5-001-drop-stable

2. Name of the topology file

   • Topology: sof-adl-max98360a-rt5682.tplg

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

   • Platform: RPL-skolas

Screenshots or console output
skolas-rev5 ~ # alsa_conformance_test.py -P hw:0,0 --test-suites test_rates --merge-thld-size 480
0 passed, 1 failed
Device Information
Name: hw:0,0
Card: sofrt5682[sof-rt5682]
Device: Speakers (*)[]
Stream: PLAYBACK
Format: ['S16_LE', 'S24_LE', 'S32_LE']
Channels: [2]
Rate: [48000]
Period_size range: [24, 4096]
Buffer_size range: [48, 16384]
Test Rates
Set rate 48000: fail - Rate error 31.474834 > threshold 10

[lgirdwood]

@Vamshigopal there is an ongoing discussion with @cujomalainey @kv2019i and others as the nature on Intel DMA is that it is opportunistic and asynchronous for PM reasons. i.e. we expect some jitter in position readback from HW as we only DMA when best for PM.

This does look like that the rate is jittery and slightly variable to userspace if sampling the DMA position and comparing to host timers. We probably need to factor this into the test i.e. add a rate +/- tolerance (and maybe this could be reported by ALSA drivers in the future as opportunistic DMA could become more common).

[lgirdwood]

@Vamshigopal pls also see #8458

[Vamshigopal]

Thanks @lgirdwood for update, Will look for more updates in #8458. Not sure whether we can add tolerance +/- based on period_size in the test.

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