Tuxedo OS und Wine

Tuxedo OS bzw aktuell zur Erstellung des Artikels Tuxedo OS 2 ist ein maßgeschneidertes Ubuntu, der gleichnamigen Augsburger Computer Firma Tuxedocomputers ohne die zusätzliche umstrittene SNAP Paketverwaltung, aber dafür mit dem sehr aktuellen KDE Neon, Pipewire und einigem mehr.

Maßgeschneidert kann als „erweitert“ verstanden werden.

So bleibt das Grundsystem gleich. Außer dass Anpassungen für die Hardware verfügbar sind, die Windows Wrapper Software Wine, mit der Windows Programme direkt unter Linux installiert und lauffähig sind. Und auch noch ein paar Optimierungen für den Grafikbeschleuniger Vulkan, dem Nachfolger von OpenGL.

Grundsätzlich kann gesagt werden, dass es ähnlich wie ein Kubuntu ist, nur aktueller und optimaler für die Hardware der Produkte von Tuxedocomputers angepasst.

Ich halte das hier in diesem Blogartikel fest, weil die Installation von Wine über die Installationsanleitung für Ubuntu über die Webseite WineHQ fehl schlägt. Aber Tuxedocomputers hat hier, wie oben schon erwähnt, ein zusätzliches Repository (angepasste Softwarequelle) mit der das Hinzufügen von Wine kein Problem mehr ist.

Da ich für meine Musikproduktion das Paket winehq-staging für die Windows Synthesizer und Audio Plugins und yabridge brauche, füge ich einfach das Småland-Repo wie auf der Webseite beschrieben hinzu – statt dem WineHQ Repo – und installiere es in der Kommandozeile (Konsole) mit

sudo apt install --install-recommends winehq-staging

Und damit kann ich nun alle Windowsprogramme in meinem Linux starten.

Quellen

Pipewire Latenz mit pw-metadata setzen

Wenn du Musikproduktion mit einer DAW z.B. Bitwig unter Linux machst, dann ist für dich das Thema Latenz sehr wichtig.

Was ist Latenz?

  1. Die Latenz (Verzögerung/Puffer) ist wichtig im Zusammenspiel zwischen dem Computer und dem Audiointerface (Audio und Midi).
  2. Je niedriger die Latenz, desto höher wird die CPU belastet, weil sie in sehr kurzen Abständen die Datenpakete verarbeiten muss. Je größer die Latenz, desto mehr Zeit darf vergehen, bis sich die CPU wieder um die Datenpakete kümmern muss.
  3. Wenn ausschließlich nur im Computer produziert wird, kann die Latenz ohne Probleme hoch sein.
  4. Ein guter Startwert ist schon mal 1024 Samples (21.3ms) – bei 48kHz.
  5. Erst wenn hier störende Verzögerungen bemerkbar sind, z.B. beim Spielen auf einem Controller oder Synthesizer und der Umsetzung auf den Computer, macht es Sinn diesen Wert zu verkleinern. Zum Beispiel wenn der Tastendruck und das Ertönen eines Sounds spürbar verzögert sind.

Eventuell interessiert dich noch der Artikel zum Thema Pipewire Realtime Konfiguration „Pipewire modul-rt Konfiguration“ , um deine Audio/Videoanwendungen noch performanter zu machen

Pipewire Metadaten lesen mit pw-metadata

Der Befehl lautet pw-metadata und kann folgendermaßen benutzt werden

pw-metadata [options] [ id [ key [ value [ type ] ] ] ]
  -h, --help     Show this help
      --version  Show version
  -r, --remote   Remote daemon name
  -l, --list     List available metadata
  -m, --monitor  Monitor metadata
  -d, --delete   Delete metadata
  -n, --name     Metadata name (default: "default")

Die ID mit pw-metadata rausfinden

pw-metadataohne weitere Angaben ergibt so eine Ausgabe, die je nach Hardware natürlich unterschiedlich ist. Die ID steht hier immer weit links id:0

odo@computer~$ pw-metadata

update: id:0 key:'default.configured.audio.sink' value:'{"name":"alsa_output.usb-SOOPERAUDIOCARD_192k-00.pro-output-0"}' type:'Spa:String:JSON'
update: id:0 key:'default.configured.audio.source' value:'{"name":"alsa_input.usb-SOOPERAUDIOCARD_192k-00.pro-input-0"}' type:'Spa:String:JSON'
update: id:0 key:'default.audio.sink' value:'{"name":"alsa_output.usb-SOOPERAUDIOCARD_192k-00.pro-output-0"}' type:'Spa:String:JSON'
update: id:0 key:'default.audio.source' value:'{"name":"alsa_input.usb-SOOPERAUDIOCARD_192k-00.pro-input-0"}' type:'Spa:String:JSON'
update: id:0 key:'default.video.source' value:'{"name":"v4l2_input.pci-0000_00_14.0-usb-0_7_1.0"}' type:'Spa:String:JSON'

Alle verfügbaren Metadaten mit pw-metadata -l anzeigen lassen

odo@computer~$ pw-metadata -l

Found "settings" metadata 32
Found "default" metadata 40
Found "route-settings" metadata 41

Alle verfügbaren settings mit pw-metadata -n settings anzeigen lassen

odo@computer~$ pw-metada -n settings

Found "settings" metadata 32  
update: id:0 key:'log.level' value:'2' type:''  
update: id:0 key:'clock.rate' value:'48000' type:''  
update: id:0 key:'clock.allowed-rates' value:'[ 48000 ]' type:''  
update: id:0 key:'clock.quantum' value:'1024' type:''  
update: id:0 key:'clock.min-quantum' value:'32' type:''  
update: id:0 key:'clock.max-quantum' value:'2048' type:''  
update: id:32 key:'clock.force-quantum' value:'64' type:'(null)'  
update: id:64 key:'clock.force-quantum' value:'64' type:'(null)'

Settings temporär setzen mit pw-metadata -n settings id key value type

Hier werden nun Samplefrequenz auf 48kHz und die Samples auf 1024 gestellt, so dass 1024/48000 = 0,021333 als 21,3 Millisekunden Latenz raus kommen.
Soll es eine niedrigere Latenz bei einer Samplefrequenz von 48kHz sein, müssen die 1024 Samples herunter gesetzt werden. z.B. 768 (16ms) , 512 (10,6ms), 256 (5,3ms), 128 (2,6ms), 64 (1,33ms), 32 (0,68ms).

pw-metadata -n settings 0 clock.rate 48000
pw-metadata -n settings 0 clock.quantum 1024

Die Konfiguration permanent machen. Auch nach einem Reboot.

Folgende Datei im folgenden Verzeichnis erstellen ~/.config/pipewire/pipewire.conf.d/choppy-under-load.conf. Sie sollte z.B. diesen Inhalt enthalten. Wenn andere Werte ausgewählt wurden, dann natürlich die anderen Werte.

context.properties = {
   default.clock.rate = 48000
   default.clock.quantum = 1024
}
Quellen
  1. Pipewire Module-rt https://docs.pipewire.org/page_module_rt.html
  2. Pipewire Docs https://docs.pipewire.org/index.html
  3. Pipewire Configuration https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire
  4. pw-metadata https://docs.pipewire.org/page_man_pw_metadata_1.html
  5. pw-top https://docs.pipewire.org/page_man_pw_top_1.html
  6. Troubleshooting & XRuns https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting#xruns
  7. Pipewire Ubuntuusers https://wiki.ubuntuusers.de/Pipewire/
  8. Pipewire Home https://pipewire.org/

Pipewire modul-rt Konfiguration

Hier findest du eine kurz & knackige Anleitung und Erklärung, wie du das Realtime Modul von Pipewire für deine Audio/Video Anwendungen einrichtest.

Für die Musikproduktion mit einer DAW z.B. Bitwig unter Linux kann dieses Thema für dich sehr wichtig sein.

Eventuell interessiert dich noch der Artikel über pw-metadata, mit dem du temporär und permanent deine Pipewire Konfigurationen verändern kannst

Benutzer in Gruppen aufnehmen

Der Benutzer unter dem die Applikation laufen soll, muss in die entsprechenden Gruppen (wenn vorhanden) aufgenommen werden mit einem Editor (z.B. nano oder vim) und Superuser Rechten die Datei /etc/group editieren

sudo vim /etc/group

und in den Zeilen, in denen rtkit und pipewire steht den Benutzernamen anhängen

rtkit:x:117:BENUTZERNAMEN
pipewire:x:136:BENUTZERNAMEN

Damit das wirksam (aktiv) wird, muss die Session neu gestartet werden. Entweder einfach ausloggen und wieder einloggen, oder den Computer neu starten.

Module-rt konfigurieren

Falls noch gar keine Pipewire Konfiguration vorhanden ist, muss diese erst angelegt werden. Das kann Systemweit in /etc/pipewire gemacht werden. Zu empfehlen ist es aber bei den meisten Systemen, da es sich meist um Eine-Person-Computer handelt im Heimverzeichnis des Benutzers z.B. /home/BENUTZERNAME/.config/pipewire/pipewire.conf.d .

Warum im Heimverzeichnis? Weil bei einem Backup des Benutzerverzeichnisses gleich die Pipewirekonfiguration der BernutzerIn mit gesichert wird. Gibt es auf dem Computer mehrere BenutzerInnen mit unterschiedlichen Konfigurationen, werden alle entsprechenden Konfigurationen mitgesichert und werden beim Zurückspielen einer Sicherung wieder „aktiviert“.

Info: Im Verzeichnis /usr/share/pipewire/ liegen bereits einige Beispiele von Konfigurationsdateien. Diese brauchen wir aber für unsere Aufgabe nicht. Und diese sind auch so generisch, dass sie nicht unbedingt auf unsere Konfiguration passen, ohne dass wir größere Änderungen an den gesamten Konfigurationsdateien vornehmen.

Konfiguration erstellen

Wir erstellen uns einfach die Datei pipewire.conf im Verzeichnis /home/Benutzername/.config/pipewire/pipewire.conf.d/ ganz einfach mit dem Aufruf eines Editors wie nano oder auch vim

vim /home/BENUTZERNAME/.config/pipewire/pipewire.conf.d/pipewire.conf

Und tragen folgende Zeilen ein. Das RTKit Modul libpipewire-module-rtkit ist hier deaktiviert und greift je nach Konfiguration nicht immer. Probiert es einfach aus, ob es bei euch funktioniert.
Darunter befindet sich dann das Pipewire Modul libpipewire-module-rt . DAS braucht ihr!

# Reload Configuration File
# systemctl --user daemon-reload
#
# Restart Pipewire Daemon 
# systemctl --user restart pipewire.service pipewire-pulse.socket

context.modules = [  

    # Uses RTKit to boost the data thread priority.
    #{ name = libpipewire-module-rtkit
    #    args = {
    #       nice.level   = -11
    #       rt.prio      = 88
    #       rt.time.soft = 2000000
    #       rt.time.hard = 2000000
    #   }
    #   flags = [ ifexists nofail ]
    #}

   # Set thread priorities without using RTKit.
   { name = libpipewire-module-rt  
       args = {  
           nice.level    = -11  
           rt.prio      = 88  
           rt.time.soft = 2000000  
           rt.time.hard = 2000000  
           rlimits.enabled = true  
           rtportal.enabled = true  
           rtkit.enabled = true  
       }  
       flags = [ ifexists nofail ]  
   }  
]

Pipewire als Benutzer neu starten

Da sich die Konfiguration auf der Festplatte geändert hat, müssen zwei Befehle mit ganz normalen Benutzerrechten eingegeben werden.

Neuladen der Konfiguration

systemctl --user daemon-reload

Pipewire neu starten

systemctl --user restart pipewire.service pipewire-pulse.socket

Check rt Prio Prozess

Mit dem folgenden Befehl kannst du im Systemjournal sehen ob eine Anwendung mit dem rtkit gestartet wurde.

journalctl --no-hostname -b 0 -e -u rtkit-daemon

Erklärung zu Xruns

Zur Vollständigkeit, weil das Thema Xruns in diesem Zusammenhang manchmal kommt.

Es gibt 2 Ursachen für Xruns

  1. Die Anwendungen können den Zyklus nicht rechtzeitig abschließen. Das kann daran liegen, dass der Kernel sie nicht rechtzeitig aufgeweckt hat oder dass sie nicht genügend Zeit zugewiesen bekommen haben.
  2. Das Timing des Treibers ist zu eng. Der Treiber wird nicht schnell genug aufgeweckt, um den Puffer gefüllt zu halten.
  • Ursache 1 kann zu Ursache 2 führen.
  • Ursache 2 kann durch Hinzufügen von mehr Pufferung (Vergrößerung des Headrooms) verbessert werden.
  • Das Hinzufügen von Headroom verbessert Ursache 1 aber nicht.

Mit pw-top kannst du sehen, was die Xruns verursacht.

  1. Wenn die Xruns der Anwendung zunehmen, ist es Ursache 1
  2. Wenn nur der Treiber die Xruns erhöht, ist es Ursache 2
  3. Wenn beide zunehmen, ist es Ursache 1, die Ursache 2 verursacht
Quellen
  1. Pipewire Module-rt https://docs.pipewire.org/page_module_rt.html
  2. Pipewire Docs https://docs.pipewire.org/index.html
  3. Pipewire Configuration https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire
  4. pw-metadata https://docs.pipewire.org/page_man_pw_metadata_1.html
  5. pw-top https://docs.pipewire.org/page_man_pw_top_1.html
  6. Troubleshooting & XRuns https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting#xruns
  7. Pipewire Ubuntuusers https://wiki.ubuntuusers.de/Pipewire/
  8. Pipewire Home https://pipewire.org/