Linux statt Windows auf dem Desktop – Nicht nur Musikproduktion

Wie Golem schreibt, erwägen wohl mittlerweile viele BenutzerInnen den Schritt auf Linux, statt von Window 10 auf Windows 11 und eventuell später auf irgendwelche monatliche Abo Varianten zu wechseln.

Da ich seit über 25 Jahren Linux auf dem Desktop nutze und immer noch absolut begeistert bin, würde ich jeden Menschen immer wieder ermutigen das auch auszuprobieren.

Um einige Zeit verschwendende Diskussionen zu vermeiden ein paar Punkte vorweg:

  1. Wer wenig visuelle Veränderungen haben will entscheidet sich für eine Linux Distribution mit KDE/Plasma z.B. die Distribution Kubuntu oder aus Deutschland das Tuxedo OS oder Mint oder eine andere Linux Distributionen
  2. Um nicht komplett ins kalte Wasser springen zu müssen, können so ziemlich alle Linux Distributionen auf einen USB Stick „installiert“ (Live-USB Stick) werden und von dort einfach mal gestartet und ausprobiert werden. Ein USB Stick ist zwar langsam, aber es geht erst mal dabei nicht um Geschwindigkeit, sondern darum, ob es läuft und einen ersten Eindruck zu bekommen. Und zum Thema Geschwindigkeit: Ein installiertes Linux ist in 99% der Fälle wesentlich schneller als ein installiertes Windows.
  3. Viele nutzen bereits schon Opensource Software, die hauptsächlich für Linux entwickelt wird. Da ist der Umstieg super einfach. Weil es gar kein Umstieg ist. Das prominenteste Beispiel dafür ist der Mozilla Firefox Browser.
  4. Viele sind über die Jahre so darauf getrimmt worden, dass sie z.B. auf Microsoft Office nicht verzichten können. Das ist aber reine Gehirnwäsche. Libreoffice bietet für 99% der Menschen mehr Funktionen, als sie tatsächlich nutzen.
  5. Eine Sache, die mir immer wieder auffällt, wenn Menschen den Wechsel von Windows zu Linux erwägen ist, dass sie aufgrund der erweiterten Möglichkeiten plötzlich vorgefertigte Funktionsanforderungen stellen, die sie zuvor noch nie hatten bzw die unter Windows nur sehr sehr umständlich möglich sind. Hier bitte die Kirche im Dorf lassen, oder sich selbst um diese hoch individualisierten Lösungen kümmern bzw die Suchmaschine dazu konsultieren. Vermutlich gibt es diese Lösung schon.
  6. Natürlich ändern sich bei einem Betriebssystemwechsel auch häufig die Namen bestimmter Softwarekomponenten. Aber auch die Eingewöhnungsphase ist recht kurz. Ich spreche da aus Erfahrung mit Menschen, die teils einfach so spontan Linux haben wollten und bis heute sehr glücklich damit sind.
  7. Ich habe im Laufe der Zeit ein paar einfach verständliche Erklär-Videos zum Thema Linux und Linux und Musikproduktion auf meinem Musikproduktions Kanal „Odo Sendaidokai“ produziert, die ich hier für alle interessierten Menschen verlinke. Und wer sich für Musikproduktion generell interessiert, ist natürlich gerne eingeladen den Kanal zu abonnieren. Seit längerer Zeit produziere ich die Videos auf Deutsch und Englisch. Inklusive regelmäßiger Livestreams auf Deutsch, in denen ich meist Tracks von Anfang an produziere bzw auch Vieles erkläre. Zum Thema Musikproduktion betreibe ich zusätzlich noch das Blog „Klangwerk“.
  8. Für die Musikproduktion unter Linux ist für dich Pipewire natürlich sehr interessant und dafür habe ich hier im Blog auch noch einige erklärende Artikel.

Hier die Liste der Linux Erklär-Videos:

  1. Linux Supersonic from Zero to Hero Musikproduktion | DE (16.01.2024)
  2. Bitwig Linux Musicproduction 11/2023 | deutsch (19.11.2023)
  3. Musikproduktion mit Linux (auch Bitwig) (12.07.2021)
  4. Windows VST mit Bitwig unter Linux (02.10.2021)
  5. Bitwig JackAudio OBS Linux (Deutsch) – UPDATE 2022 Pipewire ist jetzt der Standard (15.11.2020)

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/