Not entering sleep state due to audio

J

jbo@

Developer
On an Intel x86 based FreeBSD 13.0-RELEASE-p4 machine, putting it to sleep (using zzz) while FireFox has a tab streaming music makes the system not going to sleep and instead printing these messages over and over (indefinitely):
Code: 
pcm7: unregister: mixer busy
pcm7: Waiting for sound application to exit!
pcm7: unregister: mixer busy
pcm7: Waiting for sound application to exit!
pcm7: unregister: mixer busy
pcm7: Waiting for sound application to exit!
pcm7: unregister: mixer busy
pcm7: Waiting for sound application to exit!

How can I mitigate this? I'd certainly like to be able to put my workstation to sleep without having to manually turn of music first.
 
Hello jbodenmann,

unfortunately pulseaudio is the problem here.

Try setting oss as preferred audio output.

from firefox pkg message:

Code: 
Currently used audio backend can be inspected on `about:support` page.
Supported backends and default probing order is as follows:
- `pulse-rust` if `pulseaudio` package is installed (PULSEAUDIO option)
- `jack` if `jackit` package is installed (JACK option)
- `sndio` if `sndio` package is installed (SNDIO option)
- `alsa` if `alsa-lib` package is installed (ALSA option)
- `oss` (always available)
To force a specific backend open `about:config` page and create
`media.cubeb.backend` preference

If that doesnt help, try to disable autospawn from pulseaudio itself.

Open /usr/local/etc/pulse/client.conf and uncomment autospawn and set it to no.
 
I was able to successfully change the FireFox's audio backend to OSS.
After that, I rebooted the machine (just to be sure), made sure no other audio devices are plugged in, fired up FireFox, started streaming music and then did zzz again.
Unfortunately, the system still hangs although this time with a different message output:
Code: 
pcm8: unregister: channel pcm8:virtual:dsp8.vp0 busy (pid 8937)
pcm8: Waiting for sound application to exit!

Any ideas?
I'm confused that now it's another `pcm` device than before. But to my knowledge no other audio device is used or active when I tested this (made sure to disconnect any wireless headsets etc (by simply removing the corresponding proprietary dongle(s)).

Alexander88207 said:
unfortunately pulseaudio is the problem here.
Click to expand...
What exactly is the problem? Is the FreeBSD port/integration missing some way to tell it to stop doing its thing?
 
i experiencing similar problem, but with USB sound card, if music is playing and i decide to close notebook lid or alternatively i had video stopped ( paused ) and i need to go and close laptop lid, i getting this busy messages. this is rather a bug, and device is not freed before sleep. I have not done any thorough investigation on this to report. And i also use S3 ACPIstate for lid close, but symptoms are the same
 
jbodenmann said:
What exactly is the problem? Is the FreeBSD port/integration missing some way to tell it to stop doing its thing?
Click to expand...

I tried it on myself once and got exactly the same thing. It seems like that you really need to free the audio device, as if you want to change it. Whether you can change this somewhere i unfortunately do not know it but would still be interesting.
 
For some reason on my amd64 machine it works okay. Also running 13.0-RELEASE-p4. I also tested with the pulseaudio backend and it works just fine.

In my case I used youtube as the "tab streaming music" for the test.


Code: 
hdac0: <NVIDIA MCP61 HDA Controller> mem 0xfe024000-0xfe027fff irq 20 at device 5.0 on pci0
hdacc0: <Realtek ALC662 rev1 HDA CODEC> at cad 0 on hdac0
hdaa0: <Realtek ALC662 rev1 Audio Function Group> at nid 1 on hdacc0
 
Hmm, interesting.

Given that there are now a bunch of people experiencing pretty much the same problem (eg. this is widely/easily reproducible) I wonder what it would take to actually track down the problem and fixing it.
Unfortunately I know very little about ACPI/SleepStates and the surrounding mechanisms. I guess my first try would be to reproduce this in a VM (eg. a VirtualBox VM where one can do (an albeit flakey) USB pass-through).
 
grahamperrin said:
I subscribe to this bug:
Click to expand...

FreeBSD bug 194727 – uaudio device gets disconnected, and hangs usb until everything using /dev/mixer* is closed


2019, under suspend/resume:

k.jacker said:
… an open bug in the snd_uaudio.ko driver, that makes the computer seem to have crashed, but actually it's not, but all usb devices stall after resume if the audio device was in use.
(one can still ssh into the machine) …
Click to expand...

k.jacker please, do you still find the same set of symptoms?

In my more recent experience, bug 194727 seems to prevent suspend/sleep; the system can not reach a point where resume can be attempted.


2019, under USB DAC unplugged hangs up rest of USB devices:

stratacast1 said:
I've noticed people are generally blaming the application in these bug reports (namely this one PR 194727. Maybe it is, since perhaps FreeBSD handles these audio contexts differently than other OSes. I wonder what the other OSes do since FreeBSD relies on the program to properly handle the signals. Something tells me it's unlikely the application developers are thinking about which OS requires what signal for it to release the device
Click to expand...


<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194727#c57> may be of interest.
 
Last edited:
paulez said:
… Removing Pulseaudio resolves the issue, so that would confirm the hypothesis that it is locking the USB audio device. …
Click to expand...

I don't pretend to have a full understanding, but (given the OSS-related links above) I might loosely describe FreeBSD potential problems with USB as more broad-ranging.

Please note, this is not lack of gratitude for the work of hselasky@ and others. I'm deeply grateful for all such works. I understand that for some things, there's just no easy solution.
 
 
First scripted sleep following the update to audio/pulseaudio: success. Then, no problem when I woke the computer (and docked it at work).

Second scripted sleep (preparing to leave work): sadly, another failure, I had to force off the computer :-(

1653607496571.png

So, I reverted to autospawn = no then killed the process.

Incidentally: I didn't knowingly use any USB audio device at work, neither do I recall playing any audio.
 
You must log in or register to reply here.
Back
Top