rt-tests

[khz]

Wer sein System auf Realtime testen will kann das mit dem Programm "rt-tests". https://packages.debian.org/de/stretch/rt-tests
Eine Übersicht über Anwendung:
4.1. Cyclictest
4.2. Oscilloscope

 

[marco93]

@khz: Hast du das mal laufen lassen bzw. verstehst du den output?

 

[khz]

Nein und man braucht das auch nicht wirklich außer du kennst dich mit den Materien aus.
Ich habe es weder installiert noch jemals genutzt. Benutze
Standard immer den aktuellen RT-Kernel meiner Distribution.
Habe es nur gepostet um die Möglichkeit aufzuzeigen dass es (DIY RT Kernel Optimierung) möglich ist.

 

[bluebell]

Wenn ich einen Song nehme (in Qtractor) und schaue, wie weit ich runtergehen kann ohne xruns zu bekommen, dann schlagen sich bei meinen Xubuntus Lowlatency-Kernel besser als Realtime-Kernel. Schon mehrfach probiert. Liegt vermutlich daran, dass ein Lowlatency-Kernel bereits den schnellen Scheduler-Timer hat und meine Hauptlast von den Plugins kommt.

 

[khz]

Ich denke eine von vielen guten Möglichkeiten an all dem ist das jeder individuell, je nach LAW Schwerpunkt(e), ... und Hardware, die Kombinationen von Optimierungen, Distributions Desktop -wahl, ... relativ einfach umsetzen kann.
Da sich - Vor- und Nachteil zugleich - relativ viele Kombinationsmöglichkeiten ergeben ist das austesten evt. ... .. .
Wie gut all die Optimierungen untereinander aufeinander abgestimmt (oder auch nicht) sind ... .
Teste individuell und nehme dass was bei dir am besten läuft. Alles - zu 100 % RT - muss nicht besser sein. Das habe ich gelernt.

 

[flightvision]

Es geht ja darum, xruns in Jack zu verhindern. Das geht entweder mit größeren Buffergrößen auf Kosten der Latenz (kein Problem wenn man nur aufnimmt) oder indem man Jack optimal arbeiten lässt.

Meine Erfahrung hat mich gelehrt: Browser aus (!), pulseaudio aus (pulseaudio -k) und dann kann ich niedrige Samplegrößen einstellen. Der realtime-Kernel macht das subjektiv noch stabiler, aber mit laufendem pulseaudio habe ich gerade dort öfter Schwierigkeiten.

Aber nochmal: So oft brauche ich keine geringen Latenzen. Um einfach so aufzunehmen und sicher vor xruns zu sein wähle ich 10ms. mit dieser Vorarbeit erreiche ich 2,7ms um einen Jam "live" aufzunehmen mit 5 Spuren und 2 Calf Kompressoren in Ardour.

 

[khz]

Pulseaudio ist der letzte $foobar!
"ALSA" (Treiber) >> "Soundserver_1" (Pulseaudio) >> "Soundserver_2" (jack)
<-- sinnvoll oder sinnlos?

ICH HABE MEINE DISTRIBUTION OHNE PULSEAUDIO GEBAUT.

Was evt. eher sinnvoll wäre ist Jack "shm" nutzen zu lassen.
https://linuxmusicians.com/viewtopic.php?p=93108#p93108
(und evt. weitere Optimierungen aus meiner chaotischen Sammlung, siehe Signatur.)

ALLES IMHO!

 

[telefonhoerer]

ich meine das das eigentliche Problem die "DAW" an für sich ist. Denn die lineare Abfolge von Tonerzeugung, Bearbeitung und Speicherung in einem Prozessbaum abzubilden erzeugt einen Haufen Overhead. Wenn dann auch noch paralell Instrumente angesteuert sowie aufgenommen werden wirds chaotisch.