Real-Time Kernel

[khz]

Ein neuer RT Kernel (4.0.4-rt1) ist erschienen.

https://www.kernel.org/pub/linux/kernel/projects/rt/
http://www.spinics.net/lists/linux-rt-users/msg13357.html

 

[mark]

Eine interessante Info...

Nur um die Newbies zu beruhigen, der RT Kernel ist vollkommen überbewertet. Seit Kernel 2.6. irgendwas und erst recht seit Ver. 3 benötigt man diesen RT Kernel nicht. auf der anderen Seite gibt es Anendungsgebiete wo ein RT Kernel Sinn macht, gerade die Anbieter von Enterprise Lösungen z.B. Suse verlangen für eine RT Kernel Implementierung mehrere tsd €. Aber wie gesagt, nur zum KlimmBimm machen braucht man keinen RT Kernel, auch keine extra Musik Distro...

Alles was du brauchst ist ein Standard Ubuntu LTS, oder eine vorletzte Fedora Version mit den Planet CCRMA Repositories LTS und vorletzte Fedora darum, weil die ganz aktuellen Distros noch nicht alle Packete unterstützen, lieber eine Version früher genommen oder LTS, dann gibts keine Probleme

 

[bluebell]

Mit einem Realtime-Kernel kann man schwacher Hardware die letzten Millisekunden Latenz raustunen, aber auch nur, wenn man sich mit Plugins zurückhält.

Bei mir, derzeit mit ältlichen Xubuntus 12.04 LTS unterwegs, werkeln die Lowlatency-Kernel 3.12.
Ich komme mit meinem Focusrite Scarlett 2i2 damit bis "-p 96 -n 2" bei jackd ohne xruns runter, aber das hilft mir nichts. Denn die Realtime-CPU-Last kommt in erster Linie durch Plugins in meiner DAW (derzeit Qtractor). Die Plugins müssen bedient werden, da kann auch ein Realtime-Kernel nichts machen. Und daher muss ich letzlich doch auf "-p 256 -n 2" gehen.

Wer allerdings live spielt, der dürfte das ganz anders sehen.

 

[mark]

Keine Ahnung, ich benutze Ubuntu 14.04 LTS, SuperCollider und habe alles auf Standard gelassen. Zum Schluss ist eigentlich ein grösserer Puffer besser weil er die CPU weniger belastet, es können ja mehr Daten zwischengespeichert werden, wertvolle Zeit in der die CPU neue random generierte Flieeskommawerte in ein Array schreiben könnte. Ich habe noch nie Latenzprobleme gehabt, das Thema Latenz interesiert mich mittlerweile gar nicht mehr weil alles im Recher passiert.

 

[khz]

Mit einer minimale Distribution (z.B. Gentoo wo man die Programme für seine Hardware && Aufgabengebiet bauen kann), einem schlanken WM, keine unnötigen Dienste laufen lassen sowie die Anpassung der limits.conf
kann
man ein Echtzeitbetriebssystem haben.
Ist doch fein.
Es ist einiges seit dem 2.6.? (Jahr anno 2008?) im Kernel mit drin (==> low latency kernel), aber nicht alles. Macht ja auch kein Sinn im normalen Kernel.
War ja, soweit ich mitbekommen habe, kurz vor dem aus (RT), also leichte Diskrepanzen zwischen Kernel Hacker und RT Hacker .

 

[Drumfix]

Eigenlich braucht man einen RT Kernel nur in zwei Fällen:

1) Die CPU besitzt nur 1 Core
oder
2) Das/die Audio/Midi-Gerät(e) müssen sich der Interrupt mit anderen Komponenten teilen.

In allen anderen Fällen kann man CPU-Isolation + IRQ-Affinity verwenden und damit kernelseitig immer mit den niedrigsten Latenzen fahren, die das Audiointerface anbietet.
Damit konnte ich testweise z.B. mein Multiface mit bis zu 96kHz/64 Samples nutzen, den Onboard Sound sogar mit bis zu 192kHz/32 Samples, mit dem Standardkernel von Ubuntu.

Wenns dann doch zu XRuns kommt ist jedenfalls nicht mehr der Kernel schuld.

Und wie Mark schon richtig bemerkte braucht man das nur, wenn man mit Out-of-the-Box Equipment arbeitet.

 

[mark]

Ich bin übrigens mittlerweile wieder bei Windows angekommen, mir geht nämlich solangsam das jackd geraffel auf die nerven...

Irgendwie scheinen unter Windows auch die Grafiktreiber beser zu funktionieren, ieht alles viel schärfer aus. Ich bin unter Windows vom Internet unabhängig. PD Extended als auch SuperCollider oder Renoise sind jeweils eine Installerdatei ohne das man zusätzliche Abhängikeiten nachladen muss. Jackrouter unter Windows würde ich nicht empfehlen, das gibt nur ärger und funktioniert nicht so wie man will. Ich verbinde PD Extended oder SuperCollider mit Renoise über das VB Cable nicht das Virtual Audio Cable, das funktioniert nämlich auch nicht...

http://vb-audio.pagesperso-orange.fr/Cable/index.htm

Funktioniert like a charm, einfach installieren und man bekommt einen neuen Audioausgang oder Eingang über die man in den Programmen die Kanäle verbinden kann. Auch sehr interessant der Voicemeeter auf der selben Seite, ein virtueller Mixer für mehere Audioprogramme mit recording usw. Guckt es euch einfach mal selber an. Also in der Summe ist mir das dann doch lieber als der Linux Kram

 

[PySeq]

Ich bin übrigens mittlerweile wieder bei Windows angekommen

Nach all der Diskussion macht mich das .

 

[mark]

Unter WIndows brauch man eben auch keinen Real-Time-Kernel. Da viel die Wahl leicht.

Das kommt auch noch dazu...

Man kann Linux auch für Audio benutzen, das durfte ich lange genug am eigenen Leib spüren. Mir ist allerdings aufgefallen das Windows wesentlich professioneller ist, die klassische Windows Gui gefällt mir besser, die Grafiktreiber funktionieren gut und die ganzen Programme die ich unter Linux für die Audio Programmierung kennen gelernt habe sind Cross Plattform. Dank Linux habe ich mich zum ersten mal für die Programmierung interessiert und angefangen Programmiersprachen wie C/C++ oder PD Extended zu erlernen. Das setzte ich unter Windows 7 fort, weil Windows doch das bessere Betriebssystem für den Desktop ist. Linux ist eher für den Server (Terminal) geeignet, läuft eben sehr stabil ist sicher und kostet nichts.

 

[mark]

Achtung, Achtung, Achtung!

Ich muss mich entschuldigen, das mit Windows und Linux... Ich habe jetzt Linux lange benutzt und es ist wahr das unter Windows die Grafiktreiber irgendwie ein besseres Bild erzeugen und irgendwie hat man auch unter Windows nicht das jack geraffel im Weg. Als ich unter Windows auch das Visual C++ Studio gefunden habe, ging es bei mir voll ab...

Aber eben habe ich mich zum ersten male hingesetzt und versucht mit PD Extended und SuperCollider unter Windows produktiv zu sein. Scheisse, echt Scheisse...

In PD, jedesmal wenn ich ein rechtsklick auf ein Objekt mache und die Hilfe öffnen will, macht es Knack. Aber so richtig Knack, es unterbricht sogar richtig das laufende Audio... So kann ich nicht arbeiten... Weil man hat ja öfters mal einfach was laufen und da kann es echt nicht sein das wenn man die Hilfe zu einem Objekt öffnet so ein Mist passiert.

Dann SC, keine autovervollständigung der Syntax, unter Linux ist es so, das wenn man sogar neben der Autovervollständigung einen kleinen Tooltip angezeigt bekommt, so das man weiss welche Argumente das Modul als nächstes erwartet. Die Grafiktreiber funktionieren unter Windows besser und die Gui wirkt besser... Aber wenn ich in meinem PD knackser habe, dann kann ich damit nix anfangen und ich werde mir jetzt kein Ableton kaufen für 650 € nur weil da Max/Msp dabei ist...

Was sagt uns das? Genau... Wo ist mein Linux USB Stick... In einer halben Stunde gehts mir wieder besser, der Doktor kommt gleich.
Scheiss was auf Windows. Ich hab mir einen neuen Laptop gekauft und da war halt ein Windows Lizenzaufkleber dabei, das ist das Problem.

Das was mir grade unter Windows passiert ist, passiert dir unter Linux selbst ohne RealtimeKernel nicht

 

[PySeq]

Unter WIndows brauch man eben auch keinen Real-Time-Kernel. Da viel die Wahl leicht.

So einfach ist es aber auch nicht: Unter Windows braucht man stattdessen einen ASIO-Treiber.

In PD, jedesmal wenn ich ein rechtsklick auf ein Objekt mache und die Hilfe öffnen will, macht es Knack. Aber so richtig Knack, es unterbricht sogar richtig das laufende Audio... So kann ich nicht arbeiten...

Das könnte eben am fehlenden ASIO-Treiber liegen.

Mir ist allerdings aufgefallen das Windows wesentlich professioneller ist, die klassische Windows Gui gefällt mir besser, die Grafiktreiber funktionieren gut ... weil Windows doch das bessere Betriebssystem für den Desktop ist.

Das klassische Einheits-Windows Gui finde ich mangels Auswahl sehr langweilig, ich hab' unter Linux keinerlei Probleme mit den Grafiktreibern, die Bildschirmdarstellung ist bei mir auf beiden OS' gleich gut.
Ich kann nicht erkennen, daß Windows das bessere Betriebssystem für den Desktop sein soll. Mit Windows würde ich aus Sicherheitsgründen z.B. gar nicht ins Internet gehen. Bei Linux kann ich leichter überprüfen, ob etwas Schädliches im Hintergrund läuft.

Für Musik nehme ich auch Windows, aber das liegt nur daran, daß Cubase mit den Treibern und Editoren der Synths und Audio-Interfaces so gut zurechtkommt. Und weil es für Musikproduktion Sinn macht, alles in einem einzigen Programm zusammenzufassen (während unter Linux oft der umgekehrte Ansatz verfolgt wird).

 

[mark]

Keine Ahnung woran es liegt, ich kenne mich da sowieso nicht so gut aus, aber unter Linux funktionieren wenigstens meine Programme die ich brauche, ohne Realtimkernel und ohne Asio. Wobei ich auch hier eine Schrecksekunde hatte. Allerdings konnte ich den Fehler auch nach mehrmaligen Versuchen nicht wieder reproduzieren.

Aber es bleibt dabei, unter Linux benötigt man nicht mehr den Realtime Kernel sondern es ist viel wichtiger die limits.conf zu bearbeiten und eine entsprechende Benutzergruppe seinem account zuzuordnen so das Realtime für den User möglich wird. Wir müssen hier auch unterscheiden zwischen RT Priorität und Preemtive Realtime. Jede Linux Distro ist dazu in der Lage Realtime auszuführen, man kann auch den Programmen eine entsprcehende Priorität zuordnen. Beim preemtiven Realtime allerdings ist es so das zu 1000% sichergestellt wird das es zu keiner Zeitverzögerung kommt. So etwas könnte man eventuell so stelle ich es mir vor im Flugzeug benötigen oder bei industtriellen Robotern, aber nicht im Studio nur weil man am analogen Synth am Cutoff dreht. Hier bieten die grossen Distros spezielle Enterprise Editionen mit preeemtiven Kernel an, dieser kostet allerdings meherere tsd €.

Das einzigste was mich noch zu einem Macbook bewegen würde wäre die Tatsache das man mit SuperCollider unter Mac Standalone Applikationen compilen kann.