Solved forcing off the computer – endlessly waiting for sound application to exit at sleep/suspend time

grahamperrin

Son of Beastie

Reaction score: 798
Messages: 2,575

It's frequently necessary to force off a computer (HP EliteBook 8570p, sometimes docked) when an attempt to suspend fails, with these messages from kernel:


Code:
pcm3: unregister: mixer busy
pcm3: Waiting for sound application to exit!


I subscribe to this bug:


– however the circumstances puzzle me, because it's sometimes necessary to force off the computer after:
  • not knowingly listening, or speaking, to anything (not knowingly using any audio device)
  • not knowingly disconnecting any device.
For me, this is by far the worst aspect of using FreeBSD. If I can't reliably sleep the computer without forcing off the power – effectively losing what's in my L2ARC, and so on:
  • it's not a stable system.
Through commands such as this:

zcat /var/log/messages.3.bz2 | grep -A 1 "Waiting for sound application to exit!"

– I identified a period between two boots when, if I'm not mistaken, the symptoms occurred without an attempt to suspend. Beginning at line 563 of the attached file.

Re: <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194727#c53> a few weeks ago I created a one-line file:

/etc/syslog.d/bug194727.conf
Code:
:msg, contains, "Waiting for sound application to exit!" kern.* |while read _ ; do pkill pulseaudio || : ; done

Still, sometimes, it's necessary to press and hold the power button.

Might I have more luck with the pre-suspend script at the foot of this 2020 article?

USB audio devices on FreeBSD

Where should I save the file, how should I name it?
 

Attachments

  • mixer busy at line 563.txt
    350.9 KB · Views: 42
OP
grahamperrin

grahamperrin

Son of Beastie

Reaction score: 798
Messages: 2,575

For reference, following correspondence with David Schlachter (author of the article mentioned above):

Code:
root@mowa219-gjp4-8570p:~ # cat /dev/sndstat
Installed devices:
pcm0: <ATI R6xx (HDMI)> (play)
pcm1: <IDT 92HD81B1X (Analog 2.0+HP/2.0)> (play/rec) default
pcm2: <IDT 92HD81B1X (Analog)> (play/rec)
pcm3: <USB audio> (rec)
No devices installed from userspace.
root@mowa219-gjp4-8570p:~ # sysctl hw.snd.default_unit
hw.snd.default_unit: 1
root@mowa219-gjp4-8570p:~ # fstat | grep dsp
grahampe firefox     6470   59 /dev        178 crw-rw-rw-  dsp1.0  w
grahampe VirtualBoxVM  6163   36 /dev        558 crw-rw-rw-  dsp2.0  w
grahampe VirtualBoxVM  6333   32 /dev        174 crw-rw-rw-  dsp0.0  w
root@mowa219-gjp4-8570p:~ # cat /usr/local/sbin/suspend.sh
# Close up the USB sound card before suspend
sysctl hw.snd.default_unit=1

# Close any programs still using the sound card
while fstat | grep dsp1 2>&1; do
   fstat | grep dsp1 | cut -w -f 3 | while read pid;
      do kill -15 "$pid"
   done
done
while [ "$(ls -l /dev | grep -c dsp1)" -gt 1 ]; do
   sleep 1
done
/usr/sbin/acpiconf -s3
root@mowa219-gjp4-8570p:~ # cat /etc/devd/acpi_lid_close.conf
# devd/acpi_lid_close.conf
notify 20 {
    match "system"    "ACPI";
    match "subsystem" "Lid";
    match "notify"    "0x00";
    action "/usr/local/sbin/suspend.sh";
};
root@mowa219-gjp4-8570p:~ # sysctl hw.acpi.lid_switch_state
hw.acpi.lid_switch_state: NONE
root@mowa219-gjp4-8570p:~ #

I don't know why VirtualBoxVM was using those two devices, it's probably negligible. I always manually close all VirtualBox stuff before attempting to sleep the computer (because the data is stored on ZFS on USB; need to export the pool before sleeping).

pcm1: <IDT 92HD81B1X (Analog 2.0+HP/2.0)> (play/rec) is what's normally used …
 
OP
grahamperrin

grahamperrin

Son of Beastie

Reaction score: 798
Messages: 2,575

Success!

With playback in Firefox before closing the lid, I closed the lid, let the computer sleep for a few seconds, raised the lid, pressed the power button to wake the computer.

Result: nothing more than a crashed tab, which is fine.

1621295714008.png


I restored the tab, playback resumed.
 
OP
grahamperrin

grahamperrin

Son of Beastie

Reaction score: 798
Messages: 2,575

Sadly, three days ago:

1621684755761.png


I guess I could make my /usr/local/sbin/suspend.sh more complex but honestly, I prefer to:
  • avoid using USB devices with FreeBSD.
 
OP
grahamperrin

grahamperrin

Son of Beastie

Reaction score: 798
Messages: 2,575

In this case, the USB headset that was previously at pcm3 and pcm4 was no longer connected.

When connected (to the previously used port, left hand side of HP EliteBook 8570p): FreeBSD failed to detect the connection.

Code:
% fstat | grep dsp
% tail -f -n 0 /var/log/messages
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
^C
% cat /dev/sndstat
Installed devices:
pcm0: <ATI R6xx (HDMI)> (play)
pcm1: <IDT 92HD81B1X (Analog 2.0+HP/2.0)> (play/rec) default
pcm2: <IDT 92HD81B1X (Analog)> (play/rec)
pcm3: <USB audio> (rec)
pcm4: <USB audio> (play/rec)
No devices installed from userspace.
% time lsusb | sort
load: 0.59  cmd: sort 7881 [piperd] 38.65r 0.00u 0.00s 0% 2128k
mi_switch+0xc1 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1be pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8
^C% sudo zpool export Transcend
grahamperrin's password:
cannot unmount '/Volumes/t500/VirtualBox': pool or dataset is busy
% pkill gvfsd-trash
% sudo zpool export Transcend
% sudo zpool offline copperbowl gpt/cache-copperbowl
% time lsusb | sort
^Ctail -f -n 0 /var/log/messages
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:45:00 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:45:00 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:45:00 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:45:00 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:45:00 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:45:00 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
^C
%

Worked around by restarting the OS :-(
 
OP
grahamperrin

grahamperrin

Son of Beastie

Reaction score: 798
Messages: 2,575

After a few more incidents, I began toying with running the script manually.

Run in this way, it does not sleep the computer, but I hope that it will identify processes that must end before sleep can be attempted.

Re: the code block below
  • yesterday I chose to quit Firefox entirely before sleep
  • now (foot of the block) I see nothing to prevent sleep
– wish me luck …

Code:
# /usr/local/sbin/suspend.sh
hw.snd.default_unit: 1 -> 1
grahampe firefox     9658   92 /dev        681 crw-rw-rw-  dsp1.1  w
^C
# /usr/local/sbin/suspend.sh
hw.snd.default_unit: 1 -> 1
^C
# exit
root@mowa219-gjp4-8570p:~ # sh
# /usr/local/sbin/suspend.sh
hw.snd.default_unit: 1 -> 1
load: 0.82  cmd: sleep 12412 [nanslp] 0.38r 0.00u 0.00s 0% 1872k
mi_switch+0xc1 sleepq_catch_signals+0x2e6 sleepq_timedwait_sig+0x12 _sleep+0x199 kern_clock_nanosleep+0x1e1 sys_nanosleep+0x3b amd64_syscall+0x10c fast_syscall_common+0xf8
sleep: about 0 second(s) left out of the original 1
^C
# zpool offline copperbowl gpt/cache-copperbowl
# slowcat /usr/local/sbin/suspend.sh
# Close up the USB sound card before suspend
sysctl hw.snd.default_unit=1

# Close any programs still using the sound card
while fstat | grep dsp 2>&1; do
   fstat | grep dsp | cut -w -f 3 | while read pid;
      do kill -15 "$pid"
   done
done
while [ "$(ls -l /dev | grep -c dsp)" -gt 1 ]; do
   sleep 1
done
/usr/sbin/acpiconf -s3
# acpiconf -s 3
 
OP
grahamperrin

grahamperrin

Son of Beastie

Reaction score: 798
Messages: 2,575

No problem yesterday morning (the script found nothing to kill).

Yesterday afternoon, after the script found nothing to kill I attempted to sleep the computer. For the umpteenth time I found myself endlessly waiting for sound application to exit and had to press-and-hold the power button.

Is there a reliable way of telling whether this sound application problem will occur?
 

xchris

Member

Reaction score: 16
Messages: 87

I have the same issue on desktop , when I use the the webcam -eg with firefox- the "Waiting for sound application to exit!" spams the logs... -and the system can't hibernate
but in my case I m just unpluging the camera/killing the firefox ...
 

Alexander88207

Aspiring Daemon

Reaction score: 527
Messages: 754

The application that blocks your shutdown is pulseaudio or an application that uses Pulseaudio.

I do use the Cinnamon eviroment that uses also pulseaudio but i never had that Problem. Maybe because i do close app applications before i shutdown.

For workaround you can do killall pulseaudio before shutdown.
 
OP
grahamperrin

grahamperrin

Son of Beastie

Reaction score: 798
Messages: 2,575

Thanks,

… For workaround you can do killall pulseaudio before shutdown.

On one occasion, every kill of pulseaudio (using htop) was swifly followed by a re-run of pulseaudio.

When (from within the script) fstat | grep dsp shows nothing, and pulseaudio is automatically re-run, how can I reliably tell which processes must be killed?
 

Vull

Aspiring Daemon

Reaction score: 517
Messages: 819

... how can I reliably tell which processes must be killed?
Compare top output from before and after installing pulseaudio, maybe. I really should take the time and try to do this myself next re-install.

Haven't had any system hangs, yet(!), but pulseaudio behaves badly for me too on FreeBSD, and almost always leaves some kind of error message as it fights to stay alive during system shutdowns or restarts. Pulseaudio... can't live with it, can't live without it...
 

0ld

New Member

Reaction score: 1
Messages: 2

When (from within the script) fstat | grep dsp shows nothing, and pulseaudio is automatically re-run, how can I reliably tell which processes must be killed?
I see you're killing dsp using processes only, but your log says:
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
kill mixer users too (i.e. change your grep dsp to grep -E 'dsp|mixer'), that's what i do in my sleep script and it works every time for me
 
OP
grahamperrin

grahamperrin

Son of Beastie

Reaction score: 798
Messages: 2,575

Code:
% fstat | grep -e dsp -e mixer | sort
grahampe gtk-mixer  34798    0* pipe fffff801e8cb95d0 <-> fffff801e8cb9730      0 rw
grahampe gtk-mixer  34798    1 /dev         28 crw-rw-rw-    null  w
grahampe gtk-mixer  34798    2 /usr/home     27 -rw-------  1147058  w
grahampe gtk-mixer  34798    3* local stream fffff80039880d00 <-> fffff80217ec7d00
grahampe gtk-mixer  34798    4
grahampe gtk-mixer  34798    5
grahampe gtk-mixer  34798    6* local stream fffff801a0a82a00 <-> fffff8019f9eac00
grahampe gtk-mixer  34798    7
grahampe gtk-mixer  34798    8* local stream fffff8023a82ee00 <-> fffff80320cfda00
grahampe gtk-mixer  34798    9
grahampe gtk-mixer  34798   10
grahampe gtk-mixer  34798   11 /usr/home  32037 drwx------      12  r
grahampe gtk-mixer  34798   12 /usr/home 328023 -rw-r--r--    4563  r
grahampe gtk-mixer  34798   13 /usr/home  32037 drwx------      12  r
grahampe gtk-mixer  34798   14 /usr/home 1641571 -rw-r--r--    3895  r
grahampe gtk-mixer  34798   15
grahampe gtk-mixer  34798   wd /usr/home     16 drwxr-xr-x     170  r
grahampe gtk-mixer  34798 root /             4 drwxr-xr-x      33  r
grahampe gtk-mixer  34798 text /        2985759 -rwxr-xr-x   59928  r
grahampe kded5      33680 3167 /dev        104 crw-rw-rw-  mixer1 rw
grahampe kded5      33680 3168 /dev        104 crw-rw-rw-  mixer1 rw
grahampe kded5      33680 3169 /dev        105 crw-rw-rw-  mixer2 rw
grahampe kded5      33680 3170 /dev        525 crw-rw-rw-  mixer3 rw
grahampe kmix       33743   10 /dev        104 crw-rw-rw-  mixer1 rw
grahampe kmix       33743   11 /dev        104 crw-rw-rw-  mixer1 rw
grahampe kmix       33743   12 /dev        105 crw-rw-rw-  mixer2 rw
grahampe kmix       33743   13 /dev        525 crw-rw-rw-  mixer3 rw
grahampe pulseaudio 33748   16 /dev        104 crw-rw-rw-  mixer1 rw
grahampe pulseaudio 33748   22 /dev        104 crw-rw-rw-  mixer1 rw
grahampe pulseaudio 33748   28 /dev        105 crw-rw-rw-  mixer2 rw
grahampe pulseaudio 33748   34 /dev        525 crw-rw-rw-  mixer3 rw
% fstat | grep -e dsp -e mixer | sort
grahampe kded5      33680 3167 /dev        104 crw-rw-rw-  mixer1 rw
grahampe kded5      33680 3168 /dev        104 crw-rw-rw-  mixer1 rw
grahampe kded5      33680 3169 /dev        105 crw-rw-rw-  mixer2 rw
grahampe kded5      33680 3170 /dev        525 crw-rw-rw-  mixer3 rw
grahampe kmix       33743   10 /dev        104 crw-rw-rw-  mixer1 rw
grahampe kmix       33743   11 /dev        104 crw-rw-rw-  mixer1 rw
grahampe kmix       33743   12 /dev        105 crw-rw-rw-  mixer2 rw
grahampe kmix       33743   13 /dev        525 crw-rw-rw-  mixer3 rw
grahampe pulseaudio 33748   16 /dev        104 crw-rw-rw-  mixer1 rw
grahampe pulseaudio 33748   22 /dev        104 crw-rw-rw-  mixer1 rw
grahampe pulseaudio 33748   28 /dev        105 crw-rw-rw-  mixer2 rw
grahampe pulseaudio 33748   34 /dev        525 crw-rw-rw-  mixer3 rw
%

I know to manually close GTK-Mixer.

kded5(8) | x11/kf5-kded – requires more thought from me. Killing this daemon causes (at least) disappearance of various things from the System Tray. I can start the daemon manually, but …
 
OP
grahamperrin

grahamperrin

Son of Beastie

Reaction score: 798
Messages: 2,575

With a manual run of the current edition of /usr/local/sbin/suspend.sh:

Bash:
#!/bin/sh

# make <IDT 92HD81B1X (Analog 2.0+HP/2.0)> (play/rec) the default
sysctl hw.snd.default_unit=1

# attempt to kill all dsp- and mixer-related processes
#
while fstat | grep -e dsp -e mixer 2>&1; do
   fstat | grep -e dsp -e mixer | cut -w -f 3 | while read pid;
      do kill -15 "$pid"
   done
done
#
# I find pulseaudio not effectively killed

while [ "$(ls -l /dev | grep -c -e dsp -e mixer)" -gt 1 ]; do
   sleep 1
done
/usr/sbin/acpiconf -s3

# remember to manually run
# /usr/local/bin/kded5
# as grahamperrin after waking the computer

– results:

Code:
root@mowa219-gjp4-8570p:~ # /usr/local/sbin/suspend.sh &
[1] 37207
root@mowa219-gjp4-8570p:~ # hw.snd.default_unit: 1 -> 1
grahampe pulseaudio 35873   16 /dev        104 crw-rw-rw-  mixer1 rw
grahampe pulseaudio 35873   22 /dev        104 crw-rw-rw-  mixer1 rw
grahampe pulseaudio 35873   28 /dev        105 crw-rw-rw-  mixer2 rw
grahampe pulseaudio 35873   34 /dev        525 crw-rw-rw-  mixer3 rw
grahampe pulseaudio 35873   16 /dev        104 crw-rw-rw-  mixer1 rw
fstat: kinfo_getfile(): No such process

– then in a separate terminal, note the greater process ID:

Code:
% fstat | grep -e dsp -e mixer | sort
grahampe pulseaudio 37233   16 /dev        104 crw-rw-rw-  mixer1 rw
grahampe pulseaudio 37233   22 /dev        104 crw-rw-rw-  mixer1 rw
grahampe pulseaudio 37233   28 /dev        105 crw-rw-rw-  mixer2 rw
grahampe pulseaudio 37233   34 /dev        525 crw-rw-rw-  mixer3 rw
%

I think, we're back to this observation:

every kill of pulseaudio (using htop) was swifly followed by a re-run of pulseaudio.
 

Vull

Aspiring Daemon

Reaction score: 517
Messages: 819

I reinstalled FreeBSD 13.0 with MATE plus all my usual packages, from scratch again yesterday, repeating every step precisely, except this time I left out pulseaudio and pavucontrol. And so, I can actually get a clean shutdown now. All applications and processes exit gracefully when asked, just as I wish them to do. The sound volume (intensity?) is perhaps a trifling bit less, but the sound quality is just as good (bad?), if not better. So it's a welcome change.
 

0ld

New Member

Reaction score: 1
Messages: 2

I know to manually close GTK-Mixer.

kded5(8) | x11/kf5-kded – requires more thought from me. Killing this daemon causes (at least) disappearance of various things from the System Tray. I can start the daemon manually, but …

yea, i remember the pain when trying to sleep with the kde's love for mixers - i eventually gave up and went back to fvwm

every kill of pulseaudio (using htop) was swifly followed by a re-run of pulseaudio.

something is obviously starting pulseaudio again, i'd presume this something to be in kde, and i'd guess there is no good non-half-assed solution for sleeping with kde at the moment

the current edition of /usr/local/sbin/suspend.sh

btw, in my script i also read the current hw.snd.default_unit and the mixer vol/pcm to set them back again after waking up (because it always resets to unit 1 and default mixer settings for me)
 

Tieks

Well-Known Member

Reaction score: 124
Messages: 305

... except this time I left out pulseaudio and pavucontrol. And so, I can actually get a clean shutdown now. All applications and processes exit gracefully when asked, just as I wish them to do. The sound volume (intensity?) is perhaps a trifling bit less, but the sound quality is just as good (bad?), if not better. So it's a welcome change.
Same experience here. I used both Alsa and Pulseaudio in the past, mostly because I knew both from Linux distributions. For FreeBSD I think OSS is the better option. Less problems and easier to use.
 
OP
grahamperrin

grahamperrin

Son of Beastie

Reaction score: 798
Messages: 2,575

Working without PulseAudio is not an option for me.

Let's find a way to have pulseaudio effectively killed – without automatically restarting – prior to sleep/suspend. Thanks.
 

Vull

Aspiring Daemon

Reaction score: 517
Messages: 819

Same experience here. I used both Alsa and Pulseaudio in the past, mostly because I knew both from Linux distributions. For FreeBSD I think OSS is the better option. Less problems and easier to use.
The sound could be better, which is what prompted me to try it in the first place. Pulseaudio seems to give me a welcome gain in volume on Linux, but doesn't seem to work so well here. Maybe a little more volume but it's too tinny and harsh, with not enough bottom.
 
OP
grahamperrin

grahamperrin

Son of Beastie

Reaction score: 798
Messages: 2,575

Honestly, right now I have zero interest in the pros and cons of how things might sound whilst the OS runs.



Essentially: I want to not press and hold the power button every time when I move a notebook from one place to another. I need it to sleep.
 

Vull

Aspiring Daemon

Reaction score: 517
Messages: 819

Working without PulseAudio is not an option for me.

Let's find a way to have pulseaudio effectively killed – without automatically restarting – prior to sleep/suspend. Thanks.
Since Wednesday I messed around a bit and fine-tuned my sound without pulseaudio, because I was still unable to get adequate volume levels on some Youtube videos. Searching through the posts on this forum led me to add these lines to /etc/sysctl.conf:
Code:
dev.pcm.0.play.vchans=16
dev.pcm.0.rec.vchans=16
hw.snd.maxautovchans=16
#hw.snd.compat_linux_mmap=1
dev.pcm.0.bitperfect=1
hw.snd.vpc_0db=100
kern.timecounter.alloweddeviation=0
hw.snd.latency=0
I'm using multimedia/vlc for playing media files and added the "600% Sound Volume" add-on to Firefox and I'm really getting better volume and sound quality now than I was with pulseaudio and pavucontrol. Plus my shutdowns are clean and I can recover nicely from suspend, which I've tested even though I don't really use it. I prefer to set Power Management options to "Do Nothing" when the laptop lid is closed, and set the sleep options to "Never".

Edited to add:
https://forums.freebsd.org/threads/oss-sound-quality.69335/

https://forums.freebsd.org/threads/audio-levels-low-since-upgrading-to-13-0-release.80699/

https://mirror.as35701.net/video.fosdem.org/2019/K.3.401/freebsd_in_audio_studio.mp4

https://docs.freebsd.org/en/books/handbook/multimedia/
 

Alexander88207

Aspiring Daemon

Reaction score: 527
Messages: 754

Hello,

i think the best solution is disable pulseaudio completely, if after that everything still works as expected.

Open /usr/local/etc/pulse/client.conf and uncomment the line with
Code:
autospawn=yes
and set it to no.

Then relog or restart and pulseaudio should now no longer appear.
 
Top