Open kv2019i opened 7 months ago
FYI @RanderWang @ranj063 @ujfalusi @plbossart -- the deepbuffer PCM has some unexpected behaviour towards the user-space. Not necessarily a problem for apps that can handle this, but e.g. this won't pass the conformance test.
@kv2019i for my education, why would an application set a 100ms buffer and then ask to be awaken 10 times? The canonical ALSA behavior is for 4 periods, and the goal would actually be to use no period wake-ups and instead wake-up with a timer at the 80 or 90ms watermark.
Just trying to understand if we are dealing with a validation corner case that has no direct bearing on actual apps, or something with a direct app/product impact.
FYI @RanderWang @ranj063 @ujfalusi @plbossart -- the deepbuffer PCM has some unexpected behaviour towards the user-space. Not necessarily a problem for apps that can handle this, but e.g. this won't pass the conformance test.
The audio position has an impact for AV synchronization, assume the latency is constant if queried every 100ms, the conformance rate test should pass when --merge_threshold_t set to 0.1 sec right? but it still fails.
@kv2019i @ujfalusi @yongzhi1 I think this is solved, no? can we close?
@plbossart, with an improved alsaconformance test the reported delay is taken into account for the rate validation and it passes fine: https://github.com/ujfalusi/chromeos-audiotest/tree/topic/pcm-delay
I really don't know how that can be upstreamed back to Chrome...
@yongzhi1 @sathya-nujella can you help propagate the patches back to the Chrome repo?
@yongzhi1 @sathya-nujella can you help propagate the patches back to the Chrome repo?
Sure, maybe after the kernel series get merged to Google tree.
Testing with a new extension to alsa-conformance-test for delay reporting (https://github.com/kv2019i/cros-audiotest/tree/topic/pcm-delay-debug), shows unexpected wake-up behavior for the SOF deepbuffer PCM on Intel MTL platform.
Environment
kernel: 66ee247636e52ea6ebb136edec9abed6891d7d6c (sof-dev) SOF: 6c188298b958 (SOF main) - https://github.com/thesofproject/sof/pull/8756 needed for correct delay values but not mandatory to reproduce this bug platform: MTL topoplogy: sof-mtl-rt713-l0-rt1316-l12.tplg
Expected outcome
The driver should wake up user-space as per the configured period-size.
Additionally, INFO_BATCH should be set to indicate hw_ptr will move in jumps (see https://github.com/thesofproject/sof/issues/8717 ).
Actual outcome
If application sets a 10ms period size and 100ms buffer-size, the hw-ptr will jump 90ms at a time.
Example log (with above alsa-conformance-test version). Note, below log with FW patch https://github.com/thesofproject/sof/pull/8756 to address https://github.com/thesofproject/linux/issues/4781 -- otherwise the delay values are not correct. Not mandatory to reproduce this bug.
Notes
With defaults settings alsa-conformance-test will hit undderuns with the deepbuffer PCM and the results will not be valid. To avoid this, the block size (-B 2400) is manually set. This is the amount of data user-space writes at a time to PCM and is separate from the configured period-size.