Bitwig unter Linux

Speicherkern

Speicherkern

||||
Hallo Leute,

nach meinem Ausflug über Reason und Ableton bin ich nun bei Bitwig unter Linux gelandet. Gestern Abend und Heute habe ich fast den ganzen Tag damit verbracht meine Daten zu sichern und ein Dualboot System mit frischem Windows11 und Ubuntu Studio 25.10 aufzusetzen.

Nachdem ich meinen ersten Track seit langem mit Reason fertig gemacht hatte(Helloween Challenge) möchte ich nun bei der Synthwave Challenge alles mit Bitwig unter Linux machen. Auch bei den Plugins habe ich mir vorgenommen kein Wine oder sonst was für Geschichten zu nutzen um Windows Plugins unter Linux zum Laufen zu bekommen. Entweder gibt es das Plugin auch nativ für Linux oder ich kaufe es einfach nicht.

Was schon mal sehr überraschend war, wie weit ich mit der Latenz runter gehen konnte bis es knackt. Also unter Windows11 bin ich nur knapp bei 10ms gelandet, hier komme ich echt bis auf 1ms runter, bei 32 Buffer hat es dann schon bei dem einfachen Polysynth geknackt.

BITWIG.png

Wie sind eure Erfahrungen mit Bitwig und Linux?
 
Ja schade, ich spiele ja grundsätzlich nur mit der Computertastatur ein und unter meinem Linux klappt das mit den Keyboard Fokus nicht. Das heißt, ich kann nicht spielen und im Plugin von Drittherstellern an den Reglern drehen, denn dann bekommt das Pluginfenster den Keyboard Fokus und Bitwig senden keine MIDI Signale mehr ans Plugin.

U-he Plugins stürzen beim Versuch die GUI aufzubauen einfach ab, auch nicht schön.

Hmm, bleibt also nur mit den Stockplugins zu arbeiten.
 
Lösung: Gnome Desktop installieren

Mit dem Gnome Desktop starten sowohl die u-he Plugins und das Spielen per QWERTZ geht auch wenn ein Dritthersteller Plugin offen ist und man dann gleichzeitig darin Parameter ändert.

Ich bin eh nie ein KDE Fan gewesen, deswegen werde ich den Plasma Desktop auch keinen Tag vermissen.
 
Sehr gut.
Wie du siehst, steigt deine Lernkurve. Ich habe auf dem Gebiet Musik und Linux noch keine Erfahrungen.

Einige Fragen von mir:

Welchen Graphik-Chip nutzt du?
Ist der Low-Latency-Kernel bei dir installiert?
Läuft das System grafisch unter X.org oder Wayland?
Läuft der Audio-Stream über Jack?
Welches Audiointerface hängt an diesem Rechner?
Welches Plugin-Format nutzt du für die u-he-Sachen?
 
Ne, das klappt bei mir recht gut, aber nur jetzt unter Gnome.

Welchen Graphik-Chip nutzt du?
Nvidia 3070 RTX
Ist der Low-Latency-Kernel bei dir installiert?
Oh keine Ahnung, der der bei Ubuntu Studio 25.10 dabei ist. Laut uname ist es der hier:
6.17.0-6-generic #6-Ubuntu SMP PREEMPT_DYNAMIC Tue Oct 7 13:34:17 UTC 2025 x86_64 GNU/Linux

Läuft das System grafisch unter X.org oder Wayland?
Ich glaube die aktuelle Version nutzt nur noch Wayland als Backend
Läuft der Audio-Stream über Jack?
Ich nutze PipeWire.
Welches Audiointerface hängt an diesem Rechner?
Ich habe keine Hardware, daher brauche ich auch kein Audiointerface. Ich hatte mal eins, da ich keinerlei Unterschiede zum OnBoard Sound gehört habe, musste es wieder gehen.

Welches Plugin-Format nutzt du für die u-he-Sachen?
Ich habe Clap und auch das VST3 versucht. Clap bevorzuge ich.
 
& RT https://linuxmusicians.com/viewtopic.php?p=132670#p132670

6.17.0-6-generic #6-Ubuntu SMP PREEMPT_DYNAMIC
https://www.heise.de/news/Nach-20-J...x-Kernel-jetzt-Echtzeit-tauglich-9932733.html - ist fast, 100% wäre "apt install 6.17.0-6-rt" und

evt. noch "apt install pipewire-jack wireplumber qpwgraph (https://github.com/magillos/Cable?tab=readme-ov-file)" falls noch nicht installiert ist.

 
Zuletzt bearbeitet:
technisch@Wayland.mom
  • Do I need to worry about PipeWire (vs JACK or PulseAudio) or Wayland (vs X11)?
    • The short answer is no.
    • The long answer for PipeWire – Linux's modern, flexible audio processing engine – is that it was developed from the ground up to replace both Pulse Audio and JACK in everyday use and does so seamlessly (and with no further ado) via pipewire-jack and pipewire-pulse. While most distributions have already switched to PipeWire as their default, only a few DAWs, such as Bitwig Studio, currently support PipeWire directly. Ultimately, however, this plays a minor role in everyday use, thanks to PipeWire's backwards compatibility.
    • The long answer for Wayland is a bit more complex. As Linux's modern display server protocol, Wayland was developed as a direct replacement for X11. Thanks to Xwayland, a compatibility layer for X11 integrated into Wayland, X11 audio software or plugins work without issues in most cases on Wayland. Additionally relevant for audio plugins in particular: none of the popular audio plugin frameworks currently support Wayland directly. However, this is actively being worked on for some frameworks, such as JUCE and DPF, and workarounds exist for certain scenarios. For now, this means that if a digital audio workstation (DAW) does not offer X11 support, it can't be run on X11. For example, PreSonus' Studio One does not offer X11 support. However, such a DAW can load X11 audio plugins via Xwayland on Wayland without issue. The user won't even notice.

Edit:
old:
Linux-Soundsystem-Old.png

NEW
Linux-Soundsystem-New.png

Der aktuelle Stand des Linux Audio Stacks >>
 
Zuletzt bearbeitet:
Wenn es unter Pipewire mit so geringen Latenzen läuft ist das optimal. Jack wäre nur ein Soundserver mit dem man den Audio-Stream bzw. mehrere Audiostreams routen kann und wahrscheinlich auch mehrere Audiointerfaces entsprechend. Früher lange vor Pipewire nutzte man gerne ALSA und Jack, jetzt wohl ersetzt durch Pipewire und pipewire-jack. Ich meine, pipewire läuft im Anwenderbereich rock solid und unauffällig-unkompliziert.

Wenn du kein Audiointerface brauchst, weil kein Audio rein geht und die Ausgabe sehr gut ist, kann das durchaus ok sein. Manchmal kann ein Vergleich jedoch lohnen, da eine gute DA-Wandlung zum Abhören schon ziemlich wichtig ist. Mittlerweile gibt es billige Class-Compliant-Audiointerfaces in USB-Stick-Format, welche 24/96 können und erschreckend ok klingen.


Zu Wayland/X.org: bei mir war es in der Vergangenheit so, dass ich an meinem Linux-Arbeitsrechner einer lüftlerlose Nvidia-Grafik verbaut hatte, nachdem die originale Quadro 4000 den Hitzetot starb. Die Ruhe war nun himmlich.
Die Crux unter Linux sind oft proprietäre Treiber. Ganz vorne hier: Nvidia. Es gibt offizielle Nvidia-Treiber für Linux, die funktionieren auch meist, sind aber closed source und beißen sich oft mit anderen Komponenten, so dass nix mehr geht. D.h. die Linux-Kernel-Entwickler können Nvidia nicht berücksichtigen, da closed source und Nvidia ist da auch stur. Ergo wurde unter Linux ein Treiber "reengeneered", der Nouveaux-Treiber. Open Source. Funktioniert auch, unterstützt aber nicht alle Funktionen, was er auch nicht kann.

Ich habe früher immer den closed-source-Nvidia-Treiber in Verbindung mit X.org verwendet, da nur so das Monitor-Standby, was ich am Tag sehr oft verwende, funktionierte. Irgendwann, nach einem Kernel-Update, funktionierte das auch nicht mehr. Der Monitor wurde zwar fast dunkel aber schaltete sich nicht ordentlich ab. Also probierte ich den Nouveau-Treiber mit X.org. Da war das gleiche Spiel. Nouveaux mit Wayland ging und geht aktuell.


Der preempt_dynamic Kernel ist meines Wissens noch nicht radikal "rt". Du kannst Dir unter synaptic mal die verfügbaren Kernels anzeigen lassen. Da erscheint theoretisch auch etwas mit "rt" (realtime). Aber wenn es bei dir schon so gut läuft, kann man das sicher so lassen. Man kanns auch probieren. Rückabwickeln geht immer.

Zu Ubuntu: Sinnvoller wäre vielleicht Ubuntu 24.04 gewesen, da das ein Long Term Release ist und Support für 6 Jahre bietet. Wenn du dann noch Ubuntu Pro freischaltest (für Privatanwender kostenlos) hast Du 10 Jahre Support, was schon echt eine Menge ist. Dann kannst Du auf die nächste LTS-Version wechseln. Die erscheint alle 2 Jahre. Die nächste wäre also 26.04, wobei man hier auch immer bis zum ersten Point-Release einige Monate wartet.
Du kannst aber auch nächstes Jahr von 25.10 auf 26.04 LTS wechseln und auf LTS bleiben. Entscheidend ist, was Deine Software braucht und das ist fast nie das Modernste.


Hast Du einen ersten Eindruck von Bitwig gewinnen können?
U-He läuft ohne Einschränkungen unter Bitwig/Linux?
Unterscheidet sich das sehr von Ableton Live?
Ich meine, das Grid sieht anwenderfreundlicher aus als Max4Live. Kann mich aber auch täuschen.


Bis jetzt liest sich das schon mal sehr vielversprechend was du da schreibst. Viele hätten da schon lange aufgegeben. Aber vermutlich hast du bereits einiges an Vorwissen.
Top!

Ich warte wirklich gespannt auf deine weiteren Erlebnisse!

Danke, dass du uns an deinen Erkenntnissen teilhaben lässt - auch an die anderen hier! Echt Spitze!
 
Zuletzt bearbeitet:
@khz:
aha, also läuft ALSA noch vor pipewire und händelt auch MIDI. Ok.
 
Pipewire hat halt ein Support-Problem. Ich nutze es auch. Aber Reaper z. B. unterstützt es (noch) nicht. Mit Pipewire-Jack oder Pipewire-Alsa aber alles kein Problem. Latenzen kann ich da bisher auch keine feststellen.

Ich hätte dir allerdings auch zu 24.04 geraten. Ubuntu Studio hat übrigens schon einen RT-Kernel integriert. Ich denke aber nicht, dass das den riesigen Unterschied macht.

Dazu kann es sein, dass du den CPU-Governor auf "Performance" stellen musst. Bei DSP ist das zu empfehlen, denke ich. Das sollte prinzipiell Latenz verringern. Wenn man gerade nichts mit Audio macht, kann man ja wieder einen Gang runterschalten.
 
@RT
Der Eintrag in die /etc/security/limits.conf ist wichtig https://wiki.linuxaudio.org/wiki/system_configuration#limitsconfaudioconf und https://codeberg.org/rtcqs/rtcqs

@CPU-Governor

Robin Gareusx42
25.png
Amfe223
Jul '20

For Ardour/Mixbus, I use a default debian system with less than a handful of modifications:
Installing jackd asks to enable reatime-permissions. I don’t use jack, I only install the package to conveniently setup rt-permissons and groups. After that setting up rtirq-init (and the threadirqs kernel boot option) is sufficient. – The only manual change I made is to re-apply rtirq settings after suspend/resume cycle (similar to https://github.com/jhernberg/udev-rtirq 10).
That’s all.
On this i7, I don’t even need to change the CPU governor. CPU frequency change are orders or magnitude faster than audio process cycles.
On other systems like ARM or Raspberry Pi, the story is quite different though.


@Distribution
Nehme eine aktuelle, egal welch, je nach Kriterien. Aktueller Kernel (6.5 und drüber > 100% RT, MIDI-2.0, neuere ALSA Module), Pipewire, ... . https://distrowatch.com/
 


News


Zurück
Oben