PVA: Clusterplugin für Carola

Ihr habt es wahrscheinlich schon immer gewusst: Computer wollen die Welt erobern 😉 Die Welteroberungspläne von Carola sind da eher bescheiden, sie will nur Eure Wohnung kontrollieren 😀

PVA: Clusterplugin für Carola

Am Dienstagabend war es soweit, das neue Clusterplugin für Carola hatte Premiere bei Linux am Dienstag. Natürlich ist Carola eine von den netten und will euch nur besser dienen und da kam Ihr die Idee, sich doch auf alle brauchbaren Geräte im Heimnetz auszudehnen. Dafür brauchen wir Pipewire, denn das macht es möglich, den Lautsprecher und das Mikro eines anderen Linuxcomputers zu benutzen.

Wir brauchen Pipewiretunnel

Damit Ihr versteht was Carola hinter den Kulissen macht, werden wir das in Handarbeit durchgehen.

Zuerst brauchen wir einen TCP-Server. Dazu loggt man sich z.b. per SSH auf dem Clienten in die Desktopsession ein. Diese ist zwangsweise notwendig, weil ohne eine Desktopsession gibt es keinen Pipewireservice. Der Desktop muß nicht offen sein, der Screensafer kann ruhig an sein.

DEV=wlp2s0
IP=$(ip -h -f inet a show dev $DEV | grep inet | awk ‚{print $2;}‘ | sed -e „s/\/.*$//“|head -n 1)
pactl load-module module-native-protocol-tcp port=4656 listen=$IP
pactl load-module module-native-protocol-tcp port=4657 listen=$IP

Die Anweisungen oben extrahieren die IPv4 Adresse des PCs, solange das Device stimmt. Aber da Ihr die IP kennt, weil Ihr sonst nicht auf den Computer einloggen könntet, kann man sich eine automatische Ermittlung auch schenken. Vielleicht möchte ja jemand das beim Desktopstart automatisch machen, dann wäre es ganz hilfreich. In jedem Fall muß es eine extern erreichbare IP sein und es darf keine Firewall im Weg sein.

Wir brauchen zwei Tunnelports, einen für den Lautsprecher (4656) und einen für das Mikrofon(4657). In der neuesten Pluginversion kann man die Ports frei wählen, was es am Ende erlaubt, daß mehrere Instanzen von Carola auf verschiedenen PCs laufen können. Bevor jetzt jemand feuchte Träume bekommt, daß alle Clienten auch eine Kontrollinstanz sein können, davon würde ich dringend abraten, weil so ein Kreislauf nur zu totalen Fails führen wird.

Wofür ist es dann gedacht?

Wenn Ihr z.b. einen Heimautomatisierungsserver habt, der sich ganz speziell nur um Fenster, Türen, Steckdosen usw. kümmern soll, dann möchte man dem ja vielleicht auch von überall aus Anweisungen geben können. Das Mediacenter kann sich auf Video und Ton spezialisieren und der Rechner mit der KI-GPU auf was auch immer der tun soll 🙂 Solange jede Kontrollinstanz auf andere Keywords reagiert, ist das völlig unproblematisch, solange keine der erzeugten Antworten Triggerworte für andere Instanzen enthalten. Ihr seid gewarnt worden!

Als nächstes erstellen wir den Tunnel:

pactl load-module module-tunnel-sink server=tcp:192.168.0.109:4656 source_name=Küche
pactl load-module module-tunnel-source server=tcp:192.168.0.109:4657 source_name=Küche

Und schon ist Euer Tunnel fertig.

Kleiner Tip: auf beiden Seiten des Tunnels muß Wireplumber als Pipewire-Sessionmanager laufen, sonst funktioniert es nicht. Das wurde auf schmerzliche Weise klar, daß es mit dem Pinephone genau deswegen nicht ging. Das Paket „pipewire-pulse“ wäre auch hilfreich.

Und wie spielt man da jetzt Musik ein?

Damit durch den Tunnel Musik gesendet wird, können wir den Tunnel entweder im Pulseaudio-Lautstärkeregler als Ziel der Musikapp auswählen, oder wir verdrahten das auch in der Konsole. Eure Entscheidung!

pw-link qmmp:output_FL „Tunnel to tcp:192.168.0.109:4656/:playback_FL“
pw-link qmmp:output_FR „Tunnel to tcp:192.168.0.109:4656/:playback_FR“

Im Beispiel ist das jetzt für QMMP. Gleicher Befehl mit -d Option entfernt den Link wieder.  Das war es, wenn man das per Hand machen will. Noch einige hilfreiche Befehle:

pactl list short modules
pactl list short sinks
pactl list short sources
pactl unload-module ID

wobei die ID für das Unload bei der Liste als erste Spalte angezeigt wird.

Was macht Carola jetzt alles automatisch?

Da es ja um einen Cluster geht, gehen wir mal davon aus, daß es mehrere Geräte gibt und die nicht immer erreichbar sind. Carola detektiert also automatisch, ob ein Client erreichbar ist, ob der schon im Live-Clustersetup drin ist oder ob der nicht mehr erreichbar ist. Entsprechend dem Ergebnisses wirft sie alle toten Clienten raus und nimmt sie wieder auf, wenn sie wieder da sind. Wegen Update rebooten ist also absolut kein Problem 😉

Sollte Carola selbst neugestartet werden, detektiert sie den Ist-Zustand und hat danach wieder die volle Kontrolle. Die Tunnel brechen also nicht zusammen, wenn man den Assistenten neustartet.

Damit der Ton wirklich an alle Clienten rausgeht und man nicht jede einzelne App immer direkt verdrahten muß, wo Carola ja auch gar nicht weiß, welche überhaupt in die Clusternodes sollen, gibt es zwei „öffentliche“ Sinks: ALLTUNNEL und ALLMICS. Ist denke ich, selbsterklärend. Die Tunnel werden also nicht mit der App, sondern mit ALL* verbunden und die App gibt dann den Ton auf diese Node aus.

Das sieht dann so aus:

jede menge Verbindungen zwischen den Sinks und Sources

Oben das lokale Mikrofon, die Tunnelmikros und das Sammelsink ALLMICS, unten dann das entsprechende Lautsprechersetup. QMMP gibt hier den Ton erst an EASYEFFECTS aus, das leitet den dann an ALLTUNNEL weiter (Links im Bild). Das gesamte Bild paßt leider nicht in den Artikel, dafür ist es zu breit aufgestellt.

Ihr könnt Euch jetzt sicher denken, daß das mit beliebig vielen Tunneln funktioniert. Ich hatte heute mal den Lautsprecher meiner Eltern über einen SSH Tunnel + Pipewiretunnel angebunden und der Ton kam problemlos dort an.

Es kann aber zum Stottereffekt kommen. Das Pinephone leidet auch dadrunter. Was es genau auslöst, kann nur vermutet werden. Pipewire berichtet dann von einem Bufferunderrun, also das nicht genug Daten in den Tunnel geschoben werden konnten, was bedeutet würde, daß das Netz oder das Pine zu lahm waren. I.d.R. regelt sich das aber nach 1-2 Minuten wieder ein. Gerade jetzt habe ich ein Tablet und ein Pinephone drin (sieht man oben) und die laufen beide perfekt.

Ein Wort zu Latenzen

Ihr habt ein Netzwerk zwischen Eurem PC und dem Lautsprecher im Gerät, das geht nicht latenzfrei an der Musik vorbei. Da es sich aber um ein Multi-Room-Setup handelt, wo jedes Gerät in einem eigenen Zimmer steht, ist das nicht dramatisch, da es sich bei Gigabit nur um Millisekunden handelt. Man kann es aber deutlich wahrnehmen, da wir im Gehör nur maximal 4ms ausgleichen können. Also stellt die Geräte einfach nicht nebeneinander, dann ist alles gut 🙂

Dank Pipewires Geschwindigkeitsvorteil gegenüber Pulseaudio, sind es nur wenig mehr als 4 ms. Beim Wandern durch die Wohnung wird es nicht negativ auffallen.

Was kann man als nächstes erwarten kann

Der nächste Schritt wird dann sein, daß auf Geräte die das unterstützen, ein Videostream gesendet werden kann. Da wäre es natürlich natürlich extrem hilfreich wenn man auch einen Bildschirm dran hätte, der nicht nur die Sperrseite anzeigt.

Auch Apps auf den Endgeräten zu starten, sollte kein Problem darstellen. Mir schwebt da z.b. Netflix vor, was sich ja anbietet. Wenn das Netflixplugin dann z.b. die Anweisung „Carola spiele Netflix Enterprise in der Küche“ bekommt, könnte das den nötigen Befehl an den Cluster übergeben, der das dann an den richtigen Clienten sendet.

Möglich wäre auch, das man ein RTMP Streaming vom PC zum Clienten macht, mit MPV am Ende ist das selbst auf einem Pine 2G kein Problem, wenn die Netzwerkanbindung mitspielt.

Source: PVA@Github
Repo:  https://github.com/Cyborgscode/Personal-Voice-Assistent#how-to-install

Linux am Dienstag: von NALA, CURL und Wireplumber

Für Euch eine kleine Nachbereitung zu „Problemen mit Wireplumber“, „Curl“ und Ubuntus neuestem Paketmanager „Nala“.

Linux am Dienstag: von NALA, CURL und Wireplumber

Fangen wir mir Curl an. Mit Hilfe von Curl kann man in der Konsole Webserverseiten anfragen, Dateien Downloaden, Reaktionen testen. Dazu gibt man wie im Browser die URL an, daher auch der Namensbestandteil von Curl.

Beispiel: curl https://www.google.de/

Was passiert jetzt als erstes? Der Domainname wird aufgelöst zu einer IP ( hier: 142.250.184.227 für www.google.de). Weil wir HTTPS als Protokoll angegeben haben, geht Curl nun zu der IP auf dem Port 443 und setzte den nötigen HTTP Request ab um die Seiteninhalte zu bekommen. Soweit, so gut.

Was aber, wenn Ihr eine Webseite umgezogen habt und testen wollt, ob alles geht? Da muß man entweder die neue IP und die Domain in die /etc/hosts Datei eintragen, oder man nimmt „ncat neue.ip 80“ und schickt dann einen vorbereiteten HTTP-Request hin. Das ist für einen schnellen Test ganz schön „viel“ Arbeit, weil es mit Curl schneller geht.

Curl – Resolve

Nehmen wir mal an, die neue IP für www.google.de wäre 99.33.66.2 dann könnten wir curl so beauftragen:

curl –resolve www.google.de:80:99.33.66.2 http://www.google.de

für HTTPS wäre es dann:

curl –resolve www.google.de:443:99.33.66.2 https://www.google.de

Eine Zeile und wir wissen, daß es funktioniert oder nicht. Sehr praktisch für Webjunkies 😉

Hinweis: falls WordPress mal wieder aus den zwei Bindestrichen einen komischen macht, bitte selbstständig ändern. Nicht einfach Copy&Pasten, nachdenken!

Wie man Wireplumber in den Hintern tritt

Um zu verstehen wo das Problem lag, hier ein Screenshot der „Plumbs“ (Verbindungen) die mich echt gestört hat.

War das nervig..

Wie man sieht, haben alle , wirkliche alle, Pulseaudio-Lautstärkeregler eine Abnahme des USB-Microphones verlinkt. Das passierte am Tag des Upgrades von Fedora 34 auf 35. Warum wissen nicht mal die Pipewiregötter.

Die Folge war, daß alle Levelmeter im PAVU nur den Inputlevel vom USB-Mic angezeigt haben. Egal welches Programm sich öffnete, was man da in PAVU für Einstellungen machte, funktionierten zwar, aber es änderte sich nichts. Gut, man kann damit leben, aber warum???

Wireplumber – Streamrestore

wenn Ihr mal in Eurem Homeverzeichnis in .local/state/ schaut, seht Ihr da folgende Verzeichnisse:

[marius ~]$ ls -ls .local/state/
insgesamt 12
4 drwx——. 4 marius marius 4096 21. Okt 12:45 pipewire
4 drwx——. 2 marius marius 4096 26. Okt 09:44 wireplumber

Das Wireplumber Verzeichnis sieht ungefähr so aus:

[marius ~]$ ls -ls .local/state/wireplumber
insgesamt 16
4 -rw-r–r–. 1 marius marius 189 25. Okt 19:42 default-nodes
4 -rw-r–r–. 1 marius marius 1133 26. Okt 09:11 default-routes
8 -rw-r–r–. 1 marius marius 7761 26. Okt 10:42 restore-stream

In den Default Dateien steht drin, welches der Audiogeräte die Standardausgabe ist, und in restore-stream ist festgehalten, welche App wie mit den Aus- und Eingabegeräten verbunden war. Das wird bei Start der Desktopsession als „Stand“ wieder hergestellt, damit jede Anwendung so arbeitet, wie Ihr es zuletzt eingestellt hattet.

Jetzt schaut Euch mal meinen Stand an:

[marius ~]$ ls -ls .local/state/wireplumber.bak/
insgesamt 40
4 -rw-r–r–. 1 marius marius 194 18. Okt 21:46 default-nodes
4 -rw-r–r–. 1 marius marius 258 21. Okt 12:10 default-profile
4 -rw-r–r–. 1 marius marius 3006 21. Okt 12:47 default-routes
4 -rw-r–r–. 1 marius marius 93 30. Jul 14:47 policy-bluetooth
24 -rw-r–r–. 1 marius marius 21378 21. Okt 12:47 restore-stream

In der Datei sind jede Menge falsche Angaben gespeichert, die bei jedem Start wieder hergestellt wurden.

Der Wireplumber-Fix

Alles was Ihr machen müßt ist, das State-Verzeichnis zu löschen oder umzubenennen. Vorher sollte man den Service stoppen, damit der das nicht torpediert.

systemctl stop –user wireplumber
mv wireplumber wireplumber.bak
systemctl start –user wireplumber

und darauf kamen nicht mal die Entwickler 😉

Wo wir schon mal bei Wireplumber sind, kennt Ihr schon wpctl ?

mit wpctl status könnt Ihr Euch ansehen, was PAVU und QPWGraph Euch auch so anzeigen, nämlich wer mit dem Verbunden ist (Streams), welche Geräte es gibt ( Devices ), welche Ausgaben es gibt ( Sinks ) und wer Default ist ..

$ wpctl status ( gekürzte Ausgabe ) 

Audio
├─ Devices:
│ 43. GP107GL High Definition Audio Controller [alsa]
│ 44. Logitech Webcam C925e [alsa]
│ 45. Starship/Matisse HD Audio Controller [alsa]

├─ Sinks:
│ * 49. GP107GL High Definition Audio Controller Digital Stereo (HDMI 2) [vol: 1.00]
│ 50. Starship/Matisse HD Audio Controller Analog Stereo [vol: 1.00]

├─ Sink endpoints:

├─ Sources:
│ * 46. Logitech Webcam C925e Analog Stereo [vol: 1.00]
│ 51. Starship/Matisse HD Audio Controller Analog Stereo [vol: 0.74]

├─ Source endpoints:

└─ Streams:
69. python3.10
67. monitor_FL
68. input_FL < Logitech Webcam C925e:capture_FL [active]
72. input_FR < Logitech Webcam C925e:capture_FR [active]
76. monitor_FR

Settings
└─ Default Configured Node Names:
0. Audio/Sink alsa_output.pci-0000_0a_00.4.analog-stereo
1. Audio/Source alsa_input.usb-046d_Logitech_Webcam_C925e_F4C01DCF-02.analog-stereo

mit wpctl kann man auch die Defautl Sinks & Sources setzen:

wpctl set-default ID z.B. wpctl set-default 46 ( meine Webcam ) . Komischweise kann ich das nur für die Eingabegeräte machen, aber nicht für die Ausgaben, andere konnten das bei sich gestern schon machen. Ich ahne, da kommt noch ein Blogbeitrag zu Pipewire/Wireplumber der auch das beleuchtet 😉

Kommen wir zu NALA für Ubuntu

Nala ist ein neuer Paketmanager für Ubuntu, der eine sehr viel aufgeräumtere Darstellung des Updates macht, als APT. Ich kann Euch den nur ans Herz legen. Das APT System wird dadurch zwar inhaltlich nicht besser, aber deutlich übersichtlicher:

Bei Linux am Dienstag schauen wir nächste Woche mal das neue DNF 5 an!