Programa executado no SSH acessando pulseaudio na máquina onde ele roda

Question

Eu gostaria de executar um programa remotamente (através do ssh), mas com o áudio indo para a máquina remota onde o programa realmente é executado. Isso normalmente funcionaria com o ALSA, mas o pulseaudio aparentemente verifica algum autenticador de sessão antes de permitir a conexão de um cliente.

Como tornar essa verificação menos rigorosa?

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

    

Answer 1

O culpado é que o ssh não define DBUS_SESSION_BUS_ADDRESS que é usado para conectar ao Pulseaudio. Uma solução (baseada em este post ) foi adicionar as seguintes linhas ao meu ~/.bashrc , que são usadas quando se conecta ao ssh:

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

ele usa o PID do nautilus (você pode precisar mudar isso para obter algum processo que é sempre executado na sessão) e procura suas variáveis de ambiente por DBUS_SESSION_BUS_ADDRESS e as exporta.

Isso faz com que os programas que se conectam ao Pulse sejam executados corretamente. Outros programas que se comunicam durante o trabalho de d-bus da sessão também (como audtool por dirigir audacioso sobre a linha de comando).

    

Answer 2

No meu caso, o seguinte funcionou para mim:

pax11publish -r