Description
It has been reported [1] [2] and confirmed [3] that on MTL+ some application can render audio broken because pipewire ends up in a constant xrun loop.
Pipewire can even think that xrun happens on already running stream which otherwise would not have any problems.
The issue can be reproduced easily by forcing PW to open multiple (all) ALSA PCM devices at once:
Start a web browser and play youtube video or play audio (video is better as it will show the video stuttering)
A) start WebEx standalone application then open the Settings -> Audio
Click on the Test for Ringers and alerts (make sure that All Devices is selected), let it run and then press Stop
The audio (and video) is going stutter
B) start pavucontrol
if audio remains OK, close it and wait for PW to close the extra PCM device (use [4] for monitoring)
repeat until audio got stuttering
From kernel log it can be seen that when audio got broken all PCMs are rapidly stopped, prepared, started - a standard xrun sequence - but PW will ends up in a loop.
The reason might be that PW is not aware how SOF audio works (which is kind of similar to USB audio): SOF uses the DSP to reduce system power consumption and thus the host side DMA (the hw_ptr) is not running continuously, it is 'jumping' in bursts.
With IPC4 the SOF stack reports the 'delay' that can be used by user space to gain more insights on the progress of the audio.
[1] thesofproject/sof#9695 (comment)
[2] thesofproject/sof#9695 (comment)
[3] thesofproject/sof#9695 (comment)
[4] watch 'for pcm in /proc/asound/card*/pcm*; do echo ${pcm}; cat ${pcm}/sub0/status; done'
Cc: @lgirdwood, @kv2019i, @ranj063, @bardliao, @lvanderree, @carlinigraphy