I want to play sound on a remote machine via SSH, without X11 involvement. This should work regardless if a user is logged in to the console or X or not.

Basically, after logging in via ssh, a command line like

mpg123 test.mp3

should play the test.mp3 on this remote machine. In other words, a poor man's PA system. I allowed passwordless audio access via the network in the paprefs panel, but still no sound when I try to play via ssh.

What's the simplest and most reliable way to achieve this?

PS: Questions from the past have low-quality answers which don't answer this.

  • 1
    Just to clarify, are you able to play sounds when accessed directly via the console? – krowe Oct 11 '14 at 17:28
  • 1
    It seems that the Music Player Deamon is meant for this but I haven't tried it. – krowe Oct 11 '14 at 17:31
  • 1
    I have no problem whenn ssh into a remote debian machine and use mpg123 to play a music file remotely. So probably you have to include more informations about your setup. – mpy Oct 11 '14 at 19:25
  • @krowe: Yes, I can play sounds just fine via the console. MPD could be a solution, if it is able to play on-the-fly generated files. – emk2203 Oct 11 '14 at 21:56
  • 1
    No, you don't need a daemon for it to work. It's very likely a problem with permissions, e.g. if you are running Pulseaudio. With the right permissions, you can play sounds on the remote machine via ssh just fine. So update your question with information about how your system is configured (Pulseaudio), which errors you get, etc. Also, first try to play WAV sounds via aplay (ALSA) or paplay (Pulseaudio), that's easier to debug. Note the errors you get. – dirkt Apr 5 '17 at 8:00

Setting the DISPLAY variable to :0 solves the problem for me. Try running the command like this:

$ DISPLAY=:0 mpg123 test.mp3
  • A clever solution, but only for special case - the same user logged into both machines. If there is no user logged in or another user, you'll get Invalid MIT-MAGIC-COOKIE-1 keyxcb_connection_has_error() returned true. I don't see a solution unless you have a daemon running for the moment. Upvoted nonetheless, may help others with this special case. – emk2203 Apr 5 '17 at 6:34

With recent Ubuntu systems (17.10 in this case), it is necessary to run pulseaudio at system start or manually to get audio via ssh. pulseaudio is started on a per-user basis as default, so if nobody is logged in, you only get the null sink for your SSH login, where all audio vanishes quietly.

For a permanent solution, a systemd service could be created:

cat <<EOF >/etc/systemd/system/pulseaudio.service
Description=Pulse Audio

ExecStart=/usr/bin/pulseaudio --system --disallow-exit --disable-shm --exit-idle-time=-1


which makes sure that the pulseaudio daemon is started as the user pulse at startup. Since this is highly discouraged by the developers, the preferred solution for temporary use should be to issue sudo pulseaudio --system -D via SSH.

If a pulseaudio instance is already running, it should be killed to allow the new instance to discover the hardware. This impacts the audio for all logged-in users and should be handled on a case-by-case basis.

In any case, the logged-in user needs to be part of the pulse-access group:

sudo usermod -a -G pulse-access userName

Now it is possible to play sounds via SSH on the remote system (mpg123, mpv or others). Success can be checked by pactl list short sinks for proper audio sink detection.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.