Chciałbym uruchomić program zdalnie (przez ssh), ale z dźwiękiem przechodzącym na zdalną maszynę, na której program faktycznie działa. Normalnie działałoby to z ALSA, ale pulseaudio najwyraźniej sprawdza uwierzytelnianie sesji przed zezwoleniem na połączenie z klientem.
Jak sprawić, by ta kontrola była mniej rygorystyczna?
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
ssh
pulseaudio
eudoksos
źródło
źródło
pax11publish -r
działa na moim Ubuntu 19.10.Odpowiedzi:
W moim przypadku działało dla mnie:
źródło
Winowajcą jest to, że ssh nie ustawia,
DBUS_SESSION_BUS_ADDRESS
który jest używany do łączenia się z Pulseaudio. Rozwiązaniem (na podstawie tego postu ) było dodanie następujących wierszy do mojego~/.bashrc
, które są używane podczas łączenia przez ssh:wykorzystuje PID nautilusa (być może trzeba to zmienić, aby uzyskać jakiś proces, który zawsze jest uruchamiany w sesji) i wyszukuje jego zmienne środowiskowe
DBUS_SESSION_BUS_ADDRESS
i eksportuje je.Dzięki temu programy łączące się z Pulsem działają poprawnie. Inne programy komunikujące się w trakcie sesji d-bus również działają (np. Audtool do prowadzenia zuchwałej przez linię poleceń).
źródło
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-)
ponieważ pidof zwraca zarówno processid, jak i macierzysty processid. Ale w moim przypadku to rozwiązanie nie działa; Nadal mamconnection refused
problem.