Despite what you may read elsewhere, there are two ways to control the volume on a remote machine running PulseAudio when you can only access it via SSH.
I am not talking about using X forwarding here (which does NOT work), and I do not mean running a whole remote desktop session via VNC or X2Go just to mess with the volume.
Nor do you need to run PulseAudio as a system service, or edit PulseAudio’s configuration files at all.
This is done using command line tools only. Specifically, tmux, pulsemixer, and volumerb.
This works on a fresh install of Debian bookworm, where I have not altered any PulseAudio configuration files at all. The system in question has audio two devices – a "regular" audio output and a HDMI output.
The Problem
Because of some very good complicated security reason [1], unless you are running a system-wide configuration of PulseAudio (which is not a great idea [1]), you typically cannot connect to an already running PulseAudio daemon when you SSH into a system.
When would this come up? In my particular case so that I can adjust the volume on my media center PC from my laptop with a few simple scripts. It’s definitely one of those things not everyone will need, but when you do need it, you need it.
The Solution
For this, I’ve done the following (the PulseAudio setup is the default that Debian configured, and works perfectly fine locally):
-
sudo apt install tmux pulsemixer ruby -
wget https://raw.githubusercontent.com/uriel1998/volumerb/master/volume.rb -
sudo mv ./volume.rb /usr/local/bin/volume -
sudo chmod +x /usr/local/bin/volume - Create a tmux session, have at least one open shell window in that session, and detach from it on the machine whose volume you want to control. Not "connected via SSH", but actually on that machine.
The tmux portions are actually extra, but they give you a lot more flexibility. And if you’re regularly using SSH and don’t know about tmux, you’ll be doing yourself a lot of favors by knowing even a little about it.
pulsemixer is a fantastic TUI program for handling PulseAudio, and I thoroughly recommend it.
But, as you can see in the first video below, if I just SSH in, pulsemixer returns Failed to connect to pulseaudio. That’s also what happens if you try X-forwarding, by the way. However, you can see that – for reasons I do not understand – the volumerb script works out of the box.
That script is comparatively klunky compared to pulsemixer, but for some reason it works. The only change from that script’s normal behavior is that it only seems to work on whichever sink is set as the "default" sink, not all of the sinks.
The interesting part comes next in this second video. You have a tmux session still running on the machine that you just SSH’d into. You can attach to that existing session (tmux attach), and in any windows that were created on the local machine, you can use pulsemixer normally. It attaches to the running PulseAudio session with no difficulty.
But again, this workaround only works with windows (and sessions) that were originally created locally. In the video you can see that I create – connected over SSH – a new window. In that new window, I once again cannot connect to the PulseAudio session. But as before, volume.rb still works.
So there you go – two ways to control PulseAudio on a remote machine via SSH without running PulseAudio as a system service.
[1] I do not understand the specifics of it, nor do I understand it well enough to explain it, but just enough to take seriously the warnings that it is a Very Good Idea to not work around the security here.
Featured Image by Gerd Altmann from Pixabay