# Not entering sleep state due to audio



## jbo (Oct 27, 2021)

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):

```
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.


----------



## Alexander88207 (Oct 28, 2021)

Hello jbodenmann,

unfortunately pulseaudio is the problem here.

Try setting oss as preferred audio output.

from firefox pkg message:


```
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`.


----------



## jbo (Oct 28, 2021)

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:

```
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.


What exactly is the problem? Is the FreeBSD port/integration missing some way to tell it to stop doing its thing?


----------



## angry_vincent (Oct 28, 2021)

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


----------



## jbo (Oct 28, 2021)

angry_vincent said:


> i experiencing similar problem, but with USB sound card, [...]


If that is of any relevance: I'm also using a USB sound card in my particular scenario:

```
ugen0.4: <FiiO DigiHug USB Audio> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA)
```


----------



## Alexander88207 (Oct 28, 2021)

jbodenmann said:


> What exactly is the problem? Is the FreeBSD port/integration missing some way to tell it to stop doing its thing?



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.


----------



## dieselriot (Oct 29, 2021)

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.



```
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
```


----------



## Alexander88207 (Oct 29, 2021)

Hm.. maybe its really related to USB sound cards? 

In my test i have also used one.


----------



## grahamperrin@ (Oct 30, 2021)

I run a /usr/local/sbin/suspend.sh script.



jbodenmann said:


> 𡀦… USB sound …



The current edition of the script at <https://forums.freebsd.org/posts/531858> includes `sysctl hw.snd.default_unit=1`. You might want a different default.

I have not tried the script, recently, with USB in the mix. (I learnt, long ago, to avoid USB audio with FreeBSD, the avoidance became ingrained.) I might retry this weekend.


----------



## jbo (Oct 30, 2021)

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@ (Oct 31, 2021)

grahamperrin said:


> I subscribe to this bug:



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) …



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




<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194727#c57> may be of interest.


----------



## grahamperrin@ (Oct 31, 2021)

Also: ⚙ D11140 OSS: allow unplug sound cards without apps close devices ◀ <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220949#c1>

Postscript, 2021-12-19



grahamperrin said:


> jrm@ please, is it too late to add an idea that was _not_ expressed (here) before the summary was published?



The USB audio problem was one of two things that I forgot to suggest for FreeBSD Foundation support.


----------



## grahamperrin@ (Feb 5, 2022)

paulez said:


> … Removing Pulseaudio resolves the issue, so that would confirm the hypothesis that it is locking the USB audio device. …



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.


----------



## meaw229a (Feb 6, 2022)

Alexander88207 said:


> 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`.



Exactly this fixed it for me a few month ago. Had the same problem and set autospawn to no. 
Problem gone for good.


----------



## grahamperrin@ (May 25, 2022)

grahamperrin said:


> … <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194727> …





grahamperrin said:


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





grahamperrin said:


> Also: ⚙ D11140 OSS: allow unplug sound cards without apps close devices …



Today, in `main`:









						audio/pulseaudio: Fix for detachable USB audio devices. · freebsd/freebsd-ports@3bc8803
					

Make sure the pulseaudio OSS module does not keep the mixer device opened forever. Instead open and close the mixer device for every access. Also fix some bad code mixing get- and set- volume while...




					github.com


----------



## grahamperrin@ (May 27, 2022)

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 :-(




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.


----------

