Open Vamshigopal opened 1 year ago
@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).
@Vamshigopal pls also see https://github.com/thesofproject/sof/issues/8458
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.
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).
2) Name of the topology file
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