Programm läuft in SSH und greift auf pulseaudio auf dem Computer zu, auf dem es ausgeführt wird


10

Ich möchte ein Programm remote (über ssh) ausführen, aber mit Audio auf den Remote-Computer, auf dem das Programm tatsächlich ausgeführt wird. Dies würde normalerweise mit ALSA funktionieren, aber pulseaudio überprüft anscheinend einen Sitzungsauthentifizierer, bevor die Verbindung von einem Client zugelassen wird.

Wie kann diese Prüfung weniger streng gestaltet werden?

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

Überprüfen Sie die Antwort von Hans auf ein Update. pax11publish -rfunktioniert auf meinem Ubuntu 19.10.
Stephen Boston

Antworten:



2

Der Schuldige ist, dass ssh nicht setzt, DBUS_SESSION_BUS_ADDRESSwas verwendet wird, um sich mit Pulseaudio zu verbinden. Eine Lösung (basierend auf diesem Beitrag ) bestand darin, die folgenden Zeilen zu my hinzuzufügen ~/.bashrc, die beim Verbinden über ssh verwendet werden:

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

Es verwendet die PID von nautilus (möglicherweise müssen Sie diese ändern, um einen Prozess zu erhalten, der immer in der Sitzung ausgeführt wird) und durchsucht seine Umgebungsvariablen nach DBUS_SESSION_BUS_ADDRESSund exportiert sie.

Dadurch laufen Programme, die eine Verbindung zu Pulse herstellen, einwandfrei. Andere Programme, die über den D-Bus der Sitzung kommunizieren, funktionieren ebenfalls (z. B. Audtool zum kühnen Fahren über die Befehlszeile).


Unter Ubuntu 16.04 muss der Befehl lauten, export DBUS_SESSION_BUS_ADDRESS=$(sudo cat /proc/$(pidof nautilus | cut -f1 -d" ")/environ | tr '\0' '\n' | grep DBUS_SESSION_BUS_ADDRESS | cut -d '=' -f2-)da pidof sowohl die Prozess-ID als auch die übergeordnete Prozess-ID zurückgibt. In meinem Fall funktioniert diese Lösung jedoch nicht. Ich leide immer noch unter dem connection refusedProblem.
Hans Deragon
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.