I believe you've got to kill the PulseAudio daemon:
pulseaudio -k
... then restart it:
pulseaudio --start
... although it has respawn on by default, so it'll restart as soon as a program tries to use the sound subsystem.
FYI, the 'enable-lfe-remixing' option is deprecated.
pulseaudio --check
E: [pulseaudio] daemon-conf.c: [/etc/pulse/daemon.conf:103] Deprecated option 'enable-lfe-remixing' found.
E: [pulseaudio] daemon-conf.c: [/etc/pulse/daemon.conf:103] Please migrate to 'remixing-produce-lfe' and 'remixing-consume-lfe', set both to 'no'.
The instructions above don't change the sampling format and resolution for all interfaces:
pacmd list-sinks | grep -e 'name:' -e 'Hz'
-- or --
pacmd list-sinks | grep -E 'name:|Hz'
name: <alsa_output.usb-1130_USB_AUDIO-00.analog-stereo>
sample spec: s16le 2ch 48000Hz
name: <alsa_output.pci-0000_02_00.6.HiFi__hw_Generic_1__sink>
sample spec: s32le 2ch 48000Hz
name: <combined>
sample spec: float32le 2ch 192000Hz
I couldn't get rid of the stutter completely with 192000 Hz sampling... I think my sound card is too wimpy. In /etc/pulse/daemon.conf, I rolled back to:
default-sample-rate = 96000
alternate-sample-rate = 48000
pacmd list-sinks | grep -E 'name:|Hz'
name: <alsa_output.usb-1130_USB_AUDIO-00.analog-stereo>
sample spec: s16le 2ch 48000Hz
name: <alsa_output.pci-0000_02_00.6.HiFi__hw_Generic_1__sink>
sample spec: s32le 2ch 48000Hz
name: <combined>
sample spec: float32le 2ch 96000Hz
name: <bluez_sink.00_00_00_00_7B_FD.a2dp_sink>
sample spec: s16le 2ch 48000Hz
PulseAudio supports: 44100, 48000, 88200, 96000, 176400, 192000 Hz, although your sound card might not be able to handle all of those.
I changed:
resample-method = soxr-vhq
... to:
resample-method = speex-float-10
The soxr-vhq resample method, once it started stuttering, never recovered... it just got worse and worse until there were second-long silences in between short blips of sound. I believe that's because soxr-vhq is known to introduce lag (20 msec or more), and as it attempts to resample, the lag gets worse and worse, which necessitates more resampling, which increases lag, round and round.
With speex-float-10, even if it stutters on high CPU load, it recovers and the audio smooths out again.
You can see the various resample methods via:
pulseaudio --dump-resample-methods
If you have an older, slower CPU, try something lower such as speex-float-5, or set it to auto. Windows and MacOS use a resampling method on the order of speex-float 3 to 5. Yes, Linux can have superior audio as compared to MacOS and Windows.
daemonize = no must be set in order for pulseaudio to communicate with systemd. Since our OS uses systemd, this is required. PulseAudio will still run with daemonize = yes, but it cannot communicate with systemd.
I got rid of the deprecated:
enable-lfe-remixing = no
... and added its replacements:
remixing-produce-lfe = no
remixing-consume-lfe = no
This is the Low Frequency Effects for subwoofers. Be very careful with this... setting it when you don't have a subwoofer and a proper low-pass filter / cross-over bridge can send DC voltage across your speakers and burn the voice coils out. Subwoofers can handle that, your laptop speakers, not so much.
I changed:
default-fragments = 2
default-fragment-size-msec = 125
... to:
default-fragments = 8
default-fragment-size-msec = 20
I changed:
nice-level = -11
... to:
nice-level = -15
-20 is highest priority. It's not recommended to use that.
In /etc/pulse/default.pa, I've changed:
load-module module-suspend-on-idle
... to:
# load-module module-suspend-on-idle
And in /etc/pulse/system.pa, I've changed:
load-module module-suspend-on-idle
... to:
# load-module module-suspend-on-idle
In /etc/pulse/default.pa, I've changed:
load-module module-udev-detect
... to:
load-module module-udev-detect tsched=0
And in /etc/pulse/system.pa, I've changed:
load-module module-udev-detect
... to:
load-module module-udev-detect tsched=0
The reason for that tsched=0 is that since 0.9.14, PulseAudio uses a timer-based audio scheduling approach, rather than an interrupt-based audio scheduling approach. On high CPU load, this can cause intermittent audio. This change forces PulseAudio to use interrupt-based scheduling, and since I've set up the low-latency kernel with threaded IRQs and thread preemption, this reduces the choppiness of audio to a minimum on high CPU load (which is bound to happen from time to time for me, as I generally leave the CPU cores pegged to 400 MHz... the machine is fast enough for my use at that frequency, and if I need more computing power, it's just two clicks away).
In /etc/pipewire/pipewire.conf, under the context.properties code section, I've changed:
#default.clock.rate = 48000
... to:
default.clock.rate = 48000
I changed:
#default.clock.quantum = 1024
... to:
default.clock.quantum = 512
I've changed:
#default.clock.min-quantum = 32
... to:
default.clock.min-quantum = 32
I've changed:
#default.clock.max-quantum = 8192
... to:
default.clock.max-quantum = 4096
I'm not sure if the above settings for pipewire had any effect, but that's what I found as the recommended settings, so...
No more stuttering audio. Before, the audio (played from my phone to the computer via Bluetooth, then to a headset via Bluetooth, so I could hear both phone and computer at the same time) was smooth only as long as the Bluetooth Settings window was open and in the foreground... now it can be closed and audio is still smooth.
One caveat... do not set lock-memory = yes... for some reason, PulseAudio doesn't like that and once you kill it after changing settings, it not only won't restart, it'll kill your bluetooth as well. That's what it did on my system.
