Programma eseguito in SSH accedendo a pulseaudio sulla macchina su cui è in esecuzione

Vorrei eseguire un programma da remoto (tramite ssh) ma con l'audio che va alla macchina remota in cui il programma viene effettivamente eseguito. Questo normalmente funzionerebbe con ALSA, ma a quanto pare pulseaudio controlla alcuni autenticatori di sessione prima di consentire la connessione da un client.

Come rendere questo controllo meno severo?

local: $ ssh remote           # remote is running pulseaudio and has sound hardware

remote:$ paplay something.wav
Connection failure: Connection refused

pa_context_connect() failed: Connection refused
remote:$ audacious something.mp3 # opens on local's X11 display
pulseaudio: Failed to connect to server: Connection refused
pulseaudio: Failed to connect to server: Connection refused

Nel mio caso, per me ha funzionato:

pax11publish -r

Il colpevole è che ssh non imposta DBUS_SESSION_BUS_ADDRESSche viene utilizzato per connettersi a Pulseaudio. Una soluzione (basata su questo post ) è stata quella di aggiungere le seguenti righe a my ~/.bashrc, che vengono utilizzate durante la connessione tramite ssh:

if [[ -n $SSH_CLIENT ]]; then
    export DBUS_SESSION_BUS_ADDRESS=`cat /proc/$(pidof nautilus)/environ | tr '\0' '\n' | grep DBUS_SESSION_BUS_ADDRESS | cut -d '=' -f2-`
fi

utilizza il PID di nautilus (potrebbe essere necessario modificarlo in modo da ottenere un processo che viene sempre eseguito nella sessione) e cerca le sue variabili di ambiente per DBUS_SESSION_BUS_ADDRESSesportarlo.

In questo modo i programmi che si collegano a Pulse funzionano correttamente. Anche altri programmi che comunicano durante la sessione funzionano con il d-bus (come audtool per guidare audacemente dalla riga di comando).