pavucontrol GUI auf Remotehost ohne Xserver
pavucontrol GUI auf Remotehost ohne Xserver
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
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
Re: pavucontrol GUI auf Remotehost ohne Xserver
Wäre dann nicht ein CLI-Frontend anstelle eines GUI-Frontends sowieso die bessere Wahl?speefak hat geschrieben:26.04.2021 22:42:40Jetzt soll das ganze ohne GUI und dessen überflüssige Software funktionieren.
-
- Beiträge: 5536
- Registriert: 30.12.2004 15:31:07
- Wohnort: Wegberg
Re: pavucontrol GUI auf Remotehost ohne Xserver
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
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
Re: pavucontrol GUI auf Remotehost ohne Xserver
Ja das stimmt aber das default cli von pavucontrol ist nicht wirklich übersichtlich. Die GUI erspart da sehr viel Zeit und Nerven.
DAS scheint DIE Lösung zu sein. Werde es heute Abend direkt mal testenschwedenmann hat geschrieben:27.04.2021 11:26:45Hallo
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
Re: pavucontrol GUI auf Remotehost ohne Xserver
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 ?
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 ?
Re: pavucontrol GUI auf Remotehost ohne Xserver
Welche Funktion fehlt dir denn bei etwa pactl aus pulseaudio-utils konkret?speefak hat geschrieben:05.05.2021 13:40:36Ich habe nun mal die CLI Clients getestet, allerdings ist keiner so umfangreich in der Konfiguration wie pavucontrol.
Welchen lokalen Port? Zumindest die mir vorliegende Version ist kein Netzwerkprogramm.speefak hat geschrieben:05.05.2021 13:40:36Wie leite ich den lokalen Port von pavucontrol auf dem Host auf den Client um […]?
Re: pavucontrol GUI auf Remotehost ohne Xserver
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.
Auf dem System mit dem Pulseaudio-Server, den man remote bedienen will, muss man ein Pulseaudiomodul laden:
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
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.)
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;
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
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.)
Re: pavucontrol GUI auf Remotehost ohne Xserver
nach einigen Fehlversuchen habe ich es auch mit einem ssh-Tunnel geschafft und zwar in der Konfiguration:
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 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
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
Re: pavucontrol GUI auf Remotehost ohne Xserver
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.niemand hat geschrieben:05.05.2021 17:48:17Welche Funktion fehlt dir denn bei etwa pactl aus pulseaudio-utils konkret?speefak hat geschrieben:05.05.2021 13:40:36Ich habe nun mal die CLI Clients getestet, allerdings ist keiner so umfangreich in der Konfiguration wie pavucontrol.
Welchen lokalen Port? Zumindest die mir vorliegende Version ist kein Netzwerkprogramm.speefak hat geschrieben:05.05.2021 13:40:36Wie leite ich den lokalen Port von pavucontrol auf dem Host auf den Client um […]?
Re: pavucontrol GUI auf Remotehost ohne Xserver
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
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
Re: pavucontrol GUI auf Remotehost ohne Xserver
Für die Umleitung auf den über die Tunnel zugänglichen Server ist das
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
machen, für Dienste oder sonstwie anders gestarteten Anwendungen gibt es andere Möglichkeiten Variablen zu setzen.
Code: Alles auswählen
PULSE_SERVER="127.0.0.1:9999"
In der Shell kannst du das auch mit
Code: Alles auswählen
$ export PULSE_SERVER="127.0.0.1:9999"
$ pavucontrol
Re: pavucontrol GUI auf Remotehost ohne Xserver
Nach o.g. Bsp wäre hier :smutbert hat geschrieben:05.05.2021 21:28:30pulsemixer 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.
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:dabei stehen die X und Y für die IP-Adresse und Netzwerkmaske des Systems von dem aus man auf den Pulseaudioserver zugreifen will.Code: Alles auswählen
$ pactl load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;
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 mitZugriff auf den Pulseaudioserver haben, wobei man statt pavucontrol auch eine beliebige andere Pulseaudio-Anwendung starten kann.Code: Alles auswählen
$ PULSE_SERVER=A pavucontrol
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.)
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
Code: Alles auswählen
PULSE_SERVER=192.168.1.host pavucontrol
Ö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
Re: pavucontrol GUI auf Remotehost ohne Xserver
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.smutbert hat geschrieben:23.05.2021 13:00:17Für die Umleitung auf den über die Tunnel zugänglichen Server ist daszuständig – die Variable muss für alle Anwendungen, die sich mit dem entfernten Pulseaudioserver verbinden sollen gesetzt sein.Code: Alles auswählen
PULSE_SERVER="127.0.0.1:9999"
In der Shell kannst du das auch mitmachen, für Dienste oder sonstwie anders gestarteten Anwendungen gibt es andere Möglichkeiten Variablen zu setzen.Code: Alles auswählen
$ export PULSE_SERVER="127.0.0.1:9999" $ pavucontrol
Ich habe das Gefühl das mit der o.g Variate jeglicher sound über SSH an den PAServer geleitet wird - kann das sein ?
Re: pavucontrol GUI auf Remotehost ohne Xserver
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
EDIT => Nein
Re: pavucontrol GUI auf Remotehost ohne Xserver
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
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
Re: pavucontrol GUI auf Remotehost ohne Xserver
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:
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:
Ist ja eventuell eine Möglichkeit--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.