Environment :
- OS ( Arch Linux )
- Desktop ( KDE Plasma [Wayland] )
- Audio Server ( Pipewire v1.6.6 / pipewire-pulse )
- Hardware ( USB DAC / ALSA )
I’ve noticed when running the TeamSpeak AppImage and even the AUR version of TS that the applications internal PulseAudio client forces a quantum buffer of 360. This causes a severe mismatch with the hardware sink ( which defaults to standard powers of two like 256 / 512 resulting in heavy underruns, decimation and other audio artifact on playback streams.
Debugging
steps I took :
-
checking pw-top while a stream is active shows the hardware sink at a quantum of 256, while the TS playback stream ID 85/101 sits stubbornly at 360.
-
attempting to force a safe latency via pipewire-pulse.conf.d rules (pulse.min.quantum = 512) is entirely ignored by the appimage.
-
attempting to pass env PIPEWIRE_LATENCY=“512/48000” to the appimage execution is also ignored during sandbox mounting process.
-
my workaround - the only way to stop the aduio artifacts is to force a global hardware clock lock via the pipewire metadata API (pw-metadata -n settings 0 clock.force-quantum 512 ) which forces the image to comply and instantly clears up the audio.
Note
This might not even be TS fault, this could easily be a user config issue for all I know, but I figured I would share what I’ve been dealing with the past few months. Thanks for reading. I had recently posted this but I accidentally put it on the github for the server then was redirected to post it here.