ANZEIGE
ANZEIGE

17. Mai 2021

Workshop: Windows-Rechner per Jack mit Linux verbinden

Dieser Artikel richtet sich an Linux-Nutzer, die bereits Erfahrung mit Audio und JACK haben (auch mit Qjackctl), und die gerne einen Windows-Rechner (virtuell oder physisch) per JACK anbinden wollen – und zwar in beide Richtungen.

Ein Grund für die folgenden Schritte ist das Problem mit Windows 10 und Virtualisierern, die in vielen Fällen keinen stotterfreien Klang über den emulierten Soundchip hinbekommen. Ein anderer ist eine Installation, in der man mehrere physische Rechner am selben lokalen Netzwerk hat.

ANZEIGE

Wenn der Windows-Rechner als VM auf einem Linux-Host läuft, muss sichergestellt sein, dass die Multicasts der VM am Hauptinterface des Linux-Hosts ankommen, d.h. die VM sollte nicht über eine vom Virtualisierer angebotetenen NAT-Bridge laufen, sondern eine selbstdefinierte, transparente verwenden. Hier ein Beispiel meines Linux-Notebooks in der /etc/network/interfaces.d/lan0:

Linux: /etc/network/interfaces.d/lan0

Die Adressen sind anzupassen, meist irgendwas mit 192.168.x.x, sowie das Suchsuffix in dns-search, was man auch weglassen kann. Der Name des physischen Ethernet-Interfaces steht unter bridge_ports. Diese Definition erschafft eine Bridge namens lan0, die sich wie ein normales Netzwerk-Interface verhält, an die die VM aber in ihrer Netzwerkdefinition andocken kann:

Linux: Netzwerkdefinition des virtuellen Windows-Rechners

JACK ist auf Linux einer der vielen Soundserver neben Pulseaudio und anderen, allerdings der, der auf Pro Audio zielt und geringe Latenzen bietet. Auf Linux kann man verschiedene Soundserver koexistierend betreiben, z.B. indem Pulseaudio über JACK ausgibt. So bekommt man auch den Sound eines Webbrowsers in JACK.

JACK kann nicht nur ein lokales Audio-Interface verwalten, sondern seinen Signalweg über das Netzwerk aufspannen. Verwirrendwerweise gibt es dazu zwei Protokolle: Netjack1 und Netjack2.

Netjack1 bietet eine Punkt-zu-Punkt-Verbindung auf Netzwerkebene. Der Rechner ohne Audio-Interface startet JACK mit dem Treiber „netone“. Der Rachner mit Audio-Interface baut die Verbindung auf mit „jack_netsource -H <ip-der-Maschine-ohne-Audio-Interface>“

Netjack2 arbeitet mit Multicast. Auf dem Rechner mit Audio-Interface – dem Master – startet man den Empfänger mit „jack_net_master“ oder – wie ich es tue – lädt die Funktionalität in den laufenden JACK rein mit „jack_load netmanager“. Auf den anderen Rechnern im selben LAN – den Slaves – startet man JACK mit dem Treiber „net“. Dann erscheint auf dem Master der Slave automatisch im Graph.

Da ich mit Netjack1 nicht erfolgreich war, bezieht sich die weitere Beschreibung auf Netjack2. Es muss also jack_net_master auf dem Master gestartet oder mit „jack_load netmanager“ in den laufenden JACK geladen sein. Der Linux-Rechner ist der Master, der Windows-Rechner der Slave. Davon gehe ich nun aus.

Es reicht nicht, auf Windows JACK zu installieren, denn Windows-Programme, die JACK nutzen, sind rar. Meist nutzen Windows-Programme ASIO oder die Windows-Standard-Soundaus- und -eingabe (z.B. Audacity). Wavosaur kann zwar über ASIO ausgeben und gibt ein gutes Testprogramm ab, kann aber nicht über ASIO aufnehmen – zumindest ist es mir nicht gelungen. Wir brauchen also die gesamte Kette „Windows-Sound“ – „ASIO“ – „JACK“.

ANZEIGE

Die letzten beiden Punkte erledigt die Installation der Windows-Version von JACK, wenn man bei der Installation JackRouter und Qjackctl mitinstalliert, was die Standardeinstellung ist. Siehe dazu https://jackaudio.org/downloads/

In Qjackctl muss als Driver „net“ eingegeben werden:

Windows: Driver „net“ für JACK in Qjackctl

Auf dem Master erscheint nun nach dem Start des Windows-JACK der Slave im JACK-Graph, den Qjackctl darstellen kann:

Linux: Der Windows-Slave erscheint auf dem Linux-Master

Den kann man nun auf dem Master entsprechen verbinden – von Hand, per Qjackctl-Steckfeld/Patchbay oder per jack_plumbing.

Nun steht die JACK-Verbindung, und auf dem Windows-Slave steht ein ASIO-Treiber namens JackRouter zur Verfügung. Dieser kann seine Ein- und Ausgänge automatisch mit laufenden ASIO-Programmen verbinden, hat dabei leider einen Off-by-one-Fehler, sodass er den 2. ASIO-Port mit dem 1. JACK-Port verbindet und den 1. ASIO-Port vergisst. Daher sollte man sowohl in der 32 Bit- als auch in der 64 Bit JackRouter.ini das AUTO-CONNECT ausschalten. Dazu z.B. C:Windowsnotepad.exe als Administrator starten und die ini-Dateien editieren:

Windows: ini-Dateien für die JackBridge

Hat man es auf Windows nur mit JACK- und ASIO-Programmen zu tun, muss man den nächsten Schritt nicht tun: die Installation der Hi-Fi Cable ASIOBridge von https://vb-audio.com/Cable/index.htm#DownloadASIOBridge

Windows: ASIOBridge

Hier gilt es, im Hi-Fi Cable Input und Output sicherzustellen, dass die richtige Samplingfrequenz (wie in JACK) eingestellt ist, da es sonst zu zerhacktem und transponiertem Audio kommen kann:

Windows: Einstellungen von Hi-Fi Cable

Zum Ende stellt man im Qjackctl auf Windows noch die automatisch zu erstellenden Verbindungen im Qjackctl-Patchbay ein. Ich habe Wavosaur, den Signalgenerator ASIOSigGen und natürlich die ASIOBridge berücksichtigt:

Windows: Qjackctl-Patchbay

Für jemanden, der sich gerade in JACK einarbeitet, ist das ziemlich viel auf einmal. Ich hoffe, es hilft einigen, zumal man noch auf ganz andere Ideen kommen kann. Ausprobiert habe ich es noch nicht, aber da auf Windows auch jack_net_master.exe vorhanden ist, könnte man auf die Idee kommen, einen einfachen Windows-Rechner dazu zu nutzen, ein Audio-Interface anzuschließen und übers Netzwerk freizugeben (egal ob für Windows oder Linux), das direkt am Linux-Rechner nicht zum Laufen zu kriegen ist. Auch Windows-Rechner kann man so audiomäßig in hoher Qualität vernetzen ohne den Registrierungs- und Lizenzierungsaufwand kommerzieller Software.

ANZEIGE
Fazit
Mit dem plattformübergreifenden JACK kann man unterschiedliche Rechner audiomäßig in hoher Qualität vernetzen.

Plus

  • Funktioniert, kostenfrei, Open Source, kein Lizenzierungsaufwand

Minus

  • Einarbeitungsaufwand erforderlich
ANZEIGE
Forum
  1. Profilbild
    bluebell  AHU

    Die ASIOBridge hat ein verspieltes, aber unübersichtliches User Interface, bei dem nicht klar ist, was nun klickbar ist und was nicht.

    Damit auch was rauskommt, muss man im mittleren schwarzen Feld (türkise Schrift) auf ASIO Device klicken, um dort den JackRouter einzustellen.

  2. Profilbild
    hztirf  

    Danke für den Artikel. Als fleißiger (und langjähriger) Linux- und OSS-Nutzer, auch für Audio- und MIDI-Recording, habe ich schon viele Spielereien mit Jack und den vielen Routing-Möglichkeiten fabriziert. Meinen Windows-Rechner anzubinden kam aber noch nicht vor, „challenge accepted“.

    @bluebell, was sind deine persönlichen Anwendungsfälle für so ein Linux-Windows-Setup?

    • Profilbild
      bluebell  AHU

      Ich habe mir Melodyne gekauft. Anstatt zu versuchen, dies irgendwie mit Wine auf Linux zum Laufen zu kriegen zu versuchen und das Linux mit Closed Source Software zu verunreinigen, starte ich dafür lieber eine Windows 10-VM und lade/schreibe dort die WAVs per Samba. Ich benötige dazu eine qualitativ hochwertige Abhörmöglichkeit, damit ich auch Knackser und Unsauberkeiten beim Melodyne-Abspielen höre. Diese Qualität kriege ich nicht mit der Emulation eines Soundchips in der Windows-VM hin.

      Scream wäre eine Alternative für den Windows-Sound, kann aber kein ASIO. Und da ich in den Melodyne-Systemvoraussetzungen ASIO gelesen habe und eh JACK gut finde, bin ich den JACK-Weg gegangen.

  3. Profilbild
    swellkoerper  AHU

    Danke für den Workshop, wird garantiert ausprobiert! Welche Latenzen sind denn realistisch zu erreichen, gibt es diesbezüglich Unterschiede auf welchem OS der Jackserver läuft?

    • Profilbild
      bluebell  AHU

      Ich habe ein nicht mehr ganz taufrisches Linux-Notebook mit Core i7-7700T. Daran hängt ein MOTU UltraLite AVB. Wenn ich dort JACK mit -p128 -n3 (also 128er Puffergröße) betreibe, kann ich auf einer Windows 10 VM (auf dem selben Notebook gestartet) ohne Knackser/xruns in Melodyne Ton abspielen.

      In Millisekunden kann ich Dir das nicht sagen, und da ich derzeit keine Software-Instrumente und Plugins auf Windows habe, kann ich Dir auch nicht sagen, ob man damit flüssig spielen kann und wie es sich auswirkt, wenn man aus einer Linux-DAW Plugins unter Windows (z.B. im Plugin-Host Carla) einschleift.

      Hat man unterschiedliche physische Maschinen, dann geht das sicher mit noch geringeren Latenzen, da Latenzarmut keine Eigenschaft von virtuellen Maschinen ist.

      Da ich kein physisches Windows habe, kann ich keine Vergleiche anstellen, mit welchem OS man die geringsten Latenzen erreicht. Nur sind die eh mehr oder weniger theoretisch, weil niemand mit einem „leeren“ System arbeitet. Es sind immer die Plugins und Anwendungen, die den nötigen Puffer und somit die Latenz nach oben treiben.

      Auf der Jagd nach geringstmöglichen Latenzen würde ich in jedem Fall zu dem kleinstmöglichen Interface greifen, da es doch einen Unterschied macht, ob der Rechner 2 oder 24 oder noch mehr Kanäle vom und zum Interface schaufeln muss – und dann auch übers Netzwerk, weil sich Netjack an der Anzahl der Kanäle des Masters orientiert.

      • Profilbild
        swellkoerper  AHU

        Vielen Dank für diese wertvolle Einschätzung. Ich war nach der Lektüre deines Workshops schon euphorisch und wollte losrennen, um mir einen Laptop mit Ryzen 9 5900HS zu gönnen und meine Uralt-Maschine mit RME RayDat PCIe als Jack-Server umzuwidmen. 36 Kanäle I/O mit 32-64 Samples Latenz fällt dann wohl ins Reich der Träume, haha.
        Wobei ich zwischen Deinen Zeilen lese, dass mit zeitgemässen, leistungsfähigen physischen Maschinen sicher noch viel Optimierungspotenzial steckt. Werde das bei Gelegenheit mal abchecken.

        • Profilbild
          bluebell  AHU

          Ob 36 Kanäle mit 32-64 Samples überhaupt hinzubekommen sind, weiß ich nicht. Ich kriege auf der Linux-Kiste Guitarix und JACK mit 32 Samples zum Laufen, jedenfalls mit einem Scarlett 2i4. Mit dem MOTU geht das nicht.

    • Profilbild
      bluebell  AHU

      Ich muss noch ergänzen, dass ich kein Windows-Tuningexperte bin. Lässt man ein Windows 10 als VM laufen, fällt auf, dass die VM immer irgendwas rumwurstelt, auch wenn man ihr z.B. Defragmentierung verboten hat. Da stehen einem teilweise die Haare zu Berge, wenn eine leerlaufende Windows-VM mehr Last macht als ein arbeitender Web- und Mail- oder Datenbankserver unter Linux. Und die Ineffizienz beim Überprüfen, ob Updates anstehen, dürfte von keinem anderen Betriebssystem erreicht werden.

      Ich kann mir gut vorstellen, dass man die Zuverlässigkeit eines Windows hinsichtlich Echtzeitanforderungen noch deutlich verbessern kann, wenn man ihm sämtliche „Wartungstätigkeiten“ austreibt. Was das genau ist und ob man nach dem nächsten Update nicht wieder von vorne anfangen muss, weiß ich nicht.

Kommentar erstellen

Die AMAZONA.de-Kommentarfunktion ist Ihr Forum um sich persönlich zu den Inhalten der Artikel auszutauschen. Sich daraus ergebende Diskussionen sollten höflich und sachlich geführt werden. Haben Sie eigene Erfahrungen mit einem Produkt gemacht, stellen Sie diese bitte über die Funktion Leser-Story erstellen ein. Für persönliche Nachrichten verwenden Sie bitte die Nachrichtenfunktion im Profil.

ANZEIGE