pavucontrol GUI auf Remotehost ohne Xserver

[speefak]

Ich verzweifle gerade an Pulseaudio und der GUI Konfiguration pavucontrol auf einem Remote Host

Szenario :

Host = Debian 11 Minimalsystem mit Pulseaudio für Nutzung im Netzwerk ( MyCroft VM )
Client = Debian 10 mit vollem Gnome Desktop

Um den Sound vom Client Mikrofon in die VM zu leiten, dort von Mycroft zu bearbeiten und dann wieder an den Client auszugeben eignet sich Pulseaudio super. Die Test VM mit einem vollen Gnome Desktop lies sich einfach über Pulseaudio bzw. bzw pavucontrol einrichten - es lief.

Jetzt soll das ganze ohne GUI und dessen überflüssige Software funktionieren. Und da gehts auch schon los ... :/

Nachdem ich das Paket xauth installiert hatte und .Xauthory neu erstellt hatte ( vgl : https://superuser.com/a/941244 ) lief auch das X Forwading. Danach hatte ich mit "paprefs" die Pulseaudiogeräte freigegeben. Jetzt musste "nur noch" den Systemgeräten die entsprechenden Quellen zugeordnet werden. Geht ja super über pavucontrol - ja sch**** !

Pavucontrol über ssh forwarding geht nur leider nicht so ohne weiteres und ich habe mich bis dato so intensiv nicht Pulseaudio beschäftigt.

Wenn ich das alles richtig verstanden habe gibt es 3 Möglichkeiten :
1. Via GU auf dem Host ( idiotensicher )

2. Den Pulseaudioserver im Netzwerkfreigeben und sich dann mit "pax11publish -e -S <host>:Port?" auf den Pulseaudioservers des Hosts zu verbinden - oder so ähnlich ...
Dabei muß aber der Pulseaudioserver im Netzwerkfreigeben werden und der ist mit keinem Paßwort geschützt - oder doch ?! Stattdessen muß der Cookies des Clients auf den Host oder andersherum kopiert werden ?! Dazu muss an der Pulseaudioserver Konfiguration auch einiges geändert werden - Alles in Allem extrem umständlich, unsicher ( wenn man nicht weis was man macht ) und es hat nicht funktioniert. Ich habe keinen Port gefunden auf dem Host gefunden auf en man sich mit pax11publish hätte verbinden können. Die Umstellung des Server klappte mit "pax11publish aber das pavucontroll Fenster zeigte nur "warte auf verbindung" oder sowas in der Art.

3. Über SSH indem man den Port über den pavucontrol sich mit dem Pulseaudioserver verbindet vom Client auf den Host umleitet. Wird jetzt pavucontrol auf dem Client aufgerufen verbindet sich die GUI über den SSH umgeleiteten Port auf den Host.
Das wäre die einfachste Lösung, da kein Pulseaudioserver im Netzwerkfreigeben werden muss, die Verbindung über SSH verschlüsselt ist und keine zusätzliche Konfiguration an Pulseaudio nötig ist. Ich bin nach der Anleitung vorgegangen aber ich bekomme zum remote pavucontol einfach keine Verbindung

Lösung 3 wäre super nur wie gesagt ich stehe hier grad vollkommen auf dem Schlauch und hab grad kein Plan mehr von gar nichts :/ Ein paar Tipps wäre sehr hilfreich

[DeletedUserReAsG]

Jetzt soll das ganze ohne GUI und dessen überflüssige Software funktionieren.

Wäre dann nicht ein CLI-Frontend anstelle eines GUI-Frontends sowieso die bessere Wahl?

[schwedenmann]

Hallo

Um auf die Antwort von @niemand einzugehen

https://wiki.archlinux.org/index.php/PulseAudio#Console

dort unter Console sind dann CLI-Alternativen zu pavucontrol aufgelistet.

mfg
schwedenmann

[speefak]

Jetzt soll das ganze ohne GUI und dessen überflüssige Software funktionieren.

Wäre dann nicht ein CLI-Frontend anstelle eines GUI-Frontends sowieso die bessere Wahl?

Ja das stimmt aber das default cli von pavucontrol ist nicht wirklich übersichtlich. Die GUI erspart da sehr viel Zeit und Nerven.

Hallo

Um auf die Antwort von @niemand einzugehen

https://wiki.archlinux.org/index.php/PulseAudio#Console

dort unter Console sind dann CLI-Alternativen zu pavucontrol aufgelistet.

mfg
schwedenmann

DAS scheint DIE Lösung zu sein. Werde es heute Abend direkt mal testen

[speefak]

Ich habe nun mal die CLI Clients getestet, allerdings ist keiner so umfangreich in der Konfiguration wie pavucontrol.

Wie leite ich den lokalen Port von pavucontrol auf dem Host auf den Client um, um dann mit dem Client pavucontrol über ssh auf den Pulseaudioserver des Hosts zuzugreifen ?

[DeletedUserReAsG]

Ich habe nun mal die CLI Clients getestet, allerdings ist keiner so umfangreich in der Konfiguration wie pavucontrol.

Welche Funktion fehlt dir denn bei etwa pactl aus pulseaudio-utils konkret?

Wie leite ich den lokalen Port von pavucontrol auf dem Host auf den Client um […]?

Welchen lokalen Port? Zumindest die mir vorliegende Version ist kein Netzwerkprogramm.

[smutbert]

pulsemixer kann soweit ich das überblicke alles was pavucontrol auch kann und mit pactl auf der Kommandozeile, was unter Umständen noch praktischer ist, gibt es eigentlich auch nichts, was man nicht machen kann.

Wie leite ich den lokalen Port von pavucontrol auf dem Host auf den Client um […]?

Welchen lokalen Port? Zumindest die mir vorliegende Version ist kein Netzwerkprogramm.

Das geht grundsätzlich schon, denn Pulseaudio funktioniert problemlos über das Netzwerk.

Auf dem System mit dem Pulseaudio-Server, den man remote bedienen will, muss man ein Pulseaudiomodul laden:

Code: Alles auswählen

$ pactl load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;

dabei stehen die X und Y für die IP-Adresse und Netzwerkmaske des Systems von dem aus man auf den Pulseaudioserver zugreifen will.
127.0.0.1 davor ist bekanntlich die IP-Adresse des eigenen Systems, steht hier also für den Pulseaudioserver selbst – ich glaube nicht, dass man das wirklich angeben muss, aber weil ich nicht sicher bin und es in allen Anleitungen und Howtos, die ich gefunden habe, auch so steht, habe ich es übernommen.

Vom Client (XXX.XXX.XXX.XXX/YY) aus sollte man dann mit

Code: Alles auswählen

$ PULSE_SERVER=A pavucontrol

Zugriff auf den Pulseaudioserver haben, wobei man statt pavucontrol auch eine beliebige andere Pulseaudio-Anwendung starten kann.
A steht dabei natürlich für die IP-Adresse (oder den Hostnamen) des Pulseaudioservers.

Sicherheitstechnisch ist das aber vielleicht noch nicht das Gelbe vom Ei, weil der erlaubte Zugriff allein von der IP-Adresse abhängt.
Eventuell würde sich da ein ssh-Tunnel anbieten. Der Pulseaudioserver lauscht auf Port 4713, aber ausprobiert habe ich das mit dem Tunnel noch nicht. Mit ssh-Tunnel müsste dann das 127.0.0.1 beim Laden des Pulseaudiomoduls tatsächlich notwendig sein, dafür könnte man das XXX.XXX.XXX.XXX/YY weglassen. (Wenn du das vor mir ausprobierst, würde ich mich freuen zu lesen ob/wie es funktioniert.)

[smutbert]

nach einigen Fehlversuchen habe ich es auch mit einem ssh-Tunnel geschafft und zwar in der Konfiguration:

• Computer 1 mit Pulseaudioserver

  Code: Alles auswählen

  $ pactl load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1
  $ ssh -R 9999:127.0.0.1:4713 benutzer@computer2
  

• Computer 2 mit ssh-Server

  Code: Alles auswählen

  $ PULSE_SERVER="127.0.0.1:9999" pavucontrol
  

ich hätte es lieber in einer Variante gepostet, in der der ssh-Server und Pulseaudio auf demselben Computer laufen und der ssh-Tunnel in der anderen Richtung aufgebaut wird, aber das hat bei mir nicht geklappt und ich weiß nicht wieso.

EDIT:
Mit Hilfe (viewtopic.php?f=30&t=181003) ist es mit vertauschten ssh-Server und -Client auch kein Problem. Ganz analog zu oben, nur mit ein paar ssh-Optionen mehr, um lediglich den Tunnel aufzubauen und nicht auch eine remote-Shell zu erhalten:

• Computer 1 mit Pulseaudio- und ssh-server

  Code: Alles auswählen

  $ pactl load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1
  

• Computer 2

  Code: Alles auswählen

  $ ssh -NTfL 9999:127.0.0.1:4713 benutzer@computer1
  $ PULSE_SERVER="127.0.0.1:9999" pavucontrol
  

[speefak]

Ich habe nun mal die CLI Clients getestet, allerdings ist keiner so umfangreich in der Konfiguration wie pavucontrol.

Welche Funktion fehlt dir denn bei etwa pactl aus pulseaudio-utils konkret?

Wie leite ich den lokalen Port von pavucontrol auf dem Host auf den Client um […]?

Welchen lokalen Port? Zumindest die mir vorliegende Version ist kein Netzwerkprogramm.

Viele der o.g. CMD interfaces sind allerdings schon ewig alt. 2-3 sind noch recht aktuell. Der aus den Quellen pactl bietet sicher alle funktionen nur ist das mit den ganze Befehlen recht umständlich und im Vergleich zu pavucontrol recht unübersichtlich. Ohne SSH Tunnel müssen auch einige Konfigurationen angepaßt und Pakete nachinstalliert werden ( avahi u.a. ). Aufgrund von KISS wollte ich das vermeiden und darum über SSH gehn.

[speefak]

Zur SSH Geschichte - da is irgendwo der Wurm bei mir drin

Versuch : 1
client$> ssh -X user@host
host$> PULSE_SERVER="127.0.0.1:4713" pavucontrol

Es scheint sich pavucontroll auf dem host zu öffnen, eine Installation von z.B. Audacity auf dem Host um Aufnahmen und Ausgaben zu testen führt zu ganz komischen Ergenissen : pavu control scheint das pavucontroll vom Host zu sein. ein 2tes Terminal mit ssh -X user@host öffnen und darin audacity starten. Lt. pavucontrol auf dem host gibt es keinerlei Ein-, oder AusgabeGeräte. allerdings zeichnet Audacity Ton auf und gibt den wieder. Ich frage mich jetzt nur wie der Sound in die VM kommt ?! VM sound komplett deaktiviert ( passt ja auch da im pavucontrol keine geräte gelistet sind ) Also dürfte NUR über pulseaudio ton in und aus der VM kommen.

Es ist mir unbegreiflich

Ich weis nicht warum aber es scheint so das der gesamte Sound ( Ein und Ausgabe ) auf den Host umgeleitet werden. Das auf dem Host gestartet pavucontrol zeigt keine Geräte oder Anwendungen an, dafür werden auf dem Client das auf dem Host aufgeführte audycity als lokal gestartet angezeigt. Das kann doch nicht sein


o.g. ssh Tunnel funktionieren ebenfalls nicht, ich habe zwar ton in der VM aber der dürfte gar nicht in der VM ankommen, pulseaudio nicht umgeleitet und alle Soundoptionen in den VM einstellunge deaktiviert.

ich teste mal weiter - sehr verwirrend das Ganz hier

[smutbert]

Für die Umleitung auf den über die Tunnel zugänglichen Server ist das

Code: Alles auswählen

PULSE_SERVER="127.0.0.1:9999"

zuständig – die Variable muss für alle Anwendungen, die sich mit dem entfernten Pulseaudioserver verbinden sollen gesetzt sein.

In der Shell kannst du das auch mit

Code: Alles auswählen

$ export PULSE_SERVER="127.0.0.1:9999"
$ pavucontrol

machen, für Dienste oder sonstwie anders gestarteten Anwendungen gibt es andere Möglichkeiten Variablen zu setzen.

[speefak]

pulsemixer kann soweit ich das überblicke alles was pavucontrol auch kann und mit pactl auf der Kommandozeile, was unter Umständen noch praktischer ist, gibt es eigentlich auch nichts, was man nicht machen kann.

Wie leite ich den lokalen Port von pavucontrol auf dem Host auf den Client um […]?

Welchen lokalen Port? Zumindest die mir vorliegende Version ist kein Netzwerkprogramm.

Das geht grundsätzlich schon, denn Pulseaudio funktioniert problemlos über das Netzwerk.

Auf dem System mit dem Pulseaudio-Server, den man remote bedienen will, muss man ein Pulseaudiomodul laden:

Code: Alles auswählen

$ pactl load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;

dabei stehen die X und Y für die IP-Adresse und Netzwerkmaske des Systems von dem aus man auf den Pulseaudioserver zugreifen will.
127.0.0.1 davor ist bekanntlich die IP-Adresse des eigenen Systems, steht hier also für den Pulseaudioserver selbst – ich glaube nicht, dass man das wirklich angeben muss, aber weil ich nicht sicher bin und es in allen Anleitungen und Howtos, die ich gefunden habe, auch so steht, habe ich es übernommen.

Vom Client (XXX.XXX.XXX.XXX/YY) aus sollte man dann mit

Code: Alles auswählen

$ PULSE_SERVER=A pavucontrol

Zugriff auf den Pulseaudioserver haben, wobei man statt pavucontrol auch eine beliebige andere Pulseaudio-Anwendung starten kann.
A steht dabei natürlich für die IP-Adresse (oder den Hostnamen) des Pulseaudioservers.

Sicherheitstechnisch ist das aber vielleicht noch nicht das Gelbe vom Ei, weil der erlaubte Zugriff allein von der IP-Adresse abhängt.
Eventuell würde sich da ein ssh-Tunnel anbieten. Der Pulseaudioserver lauscht auf Port 4713, aber ausprobiert habe ich das mit dem Tunnel noch nicht. Mit ssh-Tunnel müsste dann das 127.0.0.1 beim Laden des Pulseaudiomoduls tatsächlich notwendig sein, dafür könnte man das XXX.XXX.XXX.XXX/YY weglassen. (Wenn du das vor mir ausprobierst, würde ich mich freuen zu lesen ob/wie es funktioniert.)

Nach o.g. Bsp wäre hier :

Code: Alles auswählen

ssh -X  user@192.168.1.host
Linux MyCroft 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

user@MyCroft:~> pactl load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;
30
user@MyCroft:~> pactl load-module module-native-protocol-tcp auth-ip-acl=192.168.1.client;
31

user@MyCroft:~> audacity 

Somit müsste auf dem Host die Verbindung eines pavucontrol vom client möglich sein. Vom Client kann man sich dann mit

Code: Alles auswählen

PULSE_SERVER=192.168.1.host pavucontrol

auf den pulseaudio host server verbinden. Da die Geräte des Clients mit Bezeichnung ( user@client ) jetzt im pavucontroll auftauchen und keine sonstigen scheint das vom Client aufgerufene pavucontrol ( PULSE_SERVER=192.168.1.host pavucontrol ) auf den host Pulseaudio server zuzugreifen.

Öffne ich nun pavucontrol ( beides auf dem Client eingeben ) auf dem client ( PULSE_SERVER=locatlhost pavucontrol ) und auf dem Host ( PULSE_SERVER=192.168.1.host pavucontrol ) sehe ich nur auf dem Client pavucontrol einen Ausschlag des Microfons , nicht aber auf dem Host. Die Geräte des Cleints sind beim Host zu sehen aber für das Microfon Device, das auf dem Cleint auschlägt und per paprefs an den host weitergereicht werden sollte zeigt kein Ausschlag, aber Audacity zeichnet den passenden Microfonton auf ? Das kann doch unmöglich sein - Ich werd hier echt bekloppt

[speefak]

Für die Umleitung auf den über die Tunnel zugänglichen Server ist das

Code: Alles auswählen

PULSE_SERVER="127.0.0.1:9999"

zuständig – die Variable muss für alle Anwendungen, die sich mit dem entfernten Pulseaudioserver verbinden sollen gesetzt sein.

In der Shell kannst du das auch mit

Code: Alles auswählen

$ export PULSE_SERVER="127.0.0.1:9999"
$ pavucontrol

machen, für Dienste oder sonstwie anders gestarteten Anwendungen gibt es andere Möglichkeiten Variablen zu setzen.

Entweder reden wir an einander vorbei oder ich raffs nicht. Ich möchte NUR eine pavucontrol verbindung auf den Server. Der Ton an sich soll NICHT über ssh laufen sondern über den Normalen Pulseaudio server mit den Freigeben Geräten.

Ich habe das Gefühl das mit der o.g Variate jeglicher sound über SSH an den PAServer geleitet wird - kann das sein ?

[speefak]

Wenn ich einfach nur der Client Microfon an den Host und die Hostausgabe an den Client leiten möchte, muss ich dann unter Multicast/RTP Sender und Empfänger aktivieren ?

EDIT => Nein

[smutbert]

Du willst also auf einem System sowohl auf das entfernte wie auch das lokale Pulseaudio zugreifen.
Grundsätzlich wäre das mit module-zeroconf-publish und module-zeroconf-discover (pulseaudio-module-zeroconf) kein Problem. Damit stehen die lokalen, wie auch die entfernten Audiogeräte in pavucontrol (und allen anderen Anwendungen) zur Verfügung [1], aber ich denke das hast du eh schon weitgehend herausgefunden.

Ich glaube auch nicht, dass man das zusätzlich noch durch ssh absichern kann.
Imho müsste man kreativ werden und wie ich beschrieben habe mit den ssh-Tunnel auf das remote-Pulseaudio zugreifen und die Wiedergabe vom remote-Pulseaudio wieder irgendwie auf das lokale System umleiten, z. B. mit module-tunnel-sink/module-tunnel-source oder mit einer »parec | paplay«-Kombination oder etwas ähnlichem.
(Vielleicht mache ich noch einen Vorschlag wie ich das angehen würde, wenn ich eine annehmbare Idee habe.)

[1] https://www.freedesktop.org/wiki/Softwa ... work/#mdns

[willy4711]

Spiele gerade mit xpra /firejail / firefox.
In diesem Kontext scheint mit Xpra einen Möglichkeit zu sein, PA per SSH weiterzuleiten.
Sieh dir mal das Manual an:
https://xpra.org/manual.html
und
https://wiki.archlinux.org/title/Xpra
Dort steht unter anderem:

--pulseaudio=yes|no
Enable or disable the starting of a pulseaudio server with the session.

--pulseaudio-command=SERVER-START-COMMAND
Specifies the pulseaudio command to use to start the pulseaudio server, unless disabled with pulseaudio=no.

Ist ja eventuell eine Möglichkeit