Repository navigation
Frequent Device Busy errors - pulseaudio interfering #289
Description
Seeing lots of device busy failure recently
020-07-15 08:45:13 UTC [REMOTE_COMMAND] sof-tplgreader.py /lib/firmware/intel/sof-tplg/sof-bdw-rt286.tplg -f 'type:playback' -b ' pcm:HDA Digital,Media Playback,DMIC16k' -e
2020-07-15 08:45:13 UTC [REMOTE_INFO] Testing: Low Latency [hw:0,0]
2020-07-15 08:45:13 UTC [REMOTE_COMMAND] aplay -D hw:0,0 -c 2 -r 48000 -f S16_LE /dev/zero -q
aplay: main:830: audio open error: Device or resource busy
2020-07-15 08:45:13 UTC [REMOTE_INFO] /home/ubuntu/sof-test/test-case/multiple-pipeline-playback.sh will use topology /lib/firmware/intel/sof-tplg/sof-bdw-rt286.tplg to run the test case
2020-07-15 08:45:13 UTC [REMOTE_INFO] Pipeline list to ignore is specified, will ignore 'pcm=HDA Digital,Media Playback,DMIC16k' in test case
2020-07-15 08:45:13 UTC [REMOTE_INFO] Run command to get pipeline parameters
2020-07-15 08:45:13 UTC [REMOTE_COMMAND] sof-tplgreader.py /lib/firmware/intel/sof-tplg/sof-bdw-rt286.tplg -f 'type:capture' -b ' pcm:HDA Digital,Media Playback,DMIC16k' -e
2020-07-15 08:45:13 UTC [REMOTE_INFO] Testing: Low Latency [hw:0,0]
but nothing in dmesg or sof-logger to indicate any FW or driver problems.
This is causing a poor SNR with test results.
Activity
lgirdwood commentedon Jul 15, 2020
Could something else in userspace be opening the device in these failures ? Do we check the result of close() on these devices ?
paulstelian97 commentedon Jul 15, 2020
Are we sure PA isn't causing trouble on Ubuntu 20.04?
aiChaoSONG commentedon Jul 16, 2020
@lgirdwood @paulstelian97 Pulseaudio will go through pipelines after system start up. Currently, we don't find a good way to disable and enable PA during test, so we remove PA. I am upgrading OS to Ubuntu 20.04 this week, and forget to remove PA after upgrading, that's why we see device busy. Sorry for the inconvenience, now checked PA on DUTs upgraded, issue should disappear.
lgirdwood commentedon Jul 16, 2020
@aiChaoSONG thanks, I think there is a global pulseuadio file where you can disable the respawning. i.e. this would allow your scripts to start and stop pulseaudio as needed. Please google for the details.
plbossart commentedon Jul 16, 2020
/etc/pulse/client.conf
; autospawn = yes
->
autospawn = no
aiChaoSONG commentedon Jul 17, 2020
I think @Bin-QA has tried the
audospawnoption, seems not worklgirdwood commentedon Jul 20, 2020
@Bin-QA @aiChaoSONG please also check systemd config for pulseaudio - it could be respawning. It could also be a gnome setting that's doing this too.
aiChaoSONG commentedon Jul 20, 2020
@lgirdwood We tried a lot of ways to deal with pulseaudio, but in vain. And now we temporarily remove PA at every deployment to avoid failures brought by PA. @marc-hb is trying to find a good way to disable/enable PA during test. Before he comes up with a solution, we will keeps the PA removal solution.
BTW, you shouldn't see this issue any more, because PA is 99.999999% percent removed.
marc-hb commentedon Jul 27, 2020
We de-prioritized this. If some pulseaudio testing is needed in the mean time it will be performed on other devices dedicated to pulseaudio.
[-]Frequent Device Busy errors[/-][+]Frequent Device Busy errors - pulseaudio interfering[/+]juimonen commentedon Jul 30, 2020
At least in Ubuntu I needed to do this (in addition with above mentioned config file changes, could work without them also)
stop:
systemctl --user stop pulseaudio.socket && systemctl --user stop pulseaudio.service
start:
systemctl --user start pulseaudio.socket && systemctl --user start pulseaudio.service
marc-hb commentedon Sep 3, 2020
Or this?
man journalctlmarc-hb commentedon Jul 2, 2021
Finally identified a tricky a corner case: the gdm session manager can open its own pulseaudio instance when the system is on the login screen! This is very common when running tests remotely.
The only simple way to disable this particular instance is with
--globalas insystemctl --global mask ...See more details in comments ofNew systemctl_show_pulseaudio() that catches the sneaky 'gdm' userat #728