[audio4linux]

Moin Leute,

nachdem ich hier im Forum bereits einiges über die (teilweise sehr hohen) Latenzzeiten von Jack gelesen habe, möchte ich Euch nun einen kleinen Trick mit Jack verraten:

Jack legt standardmäßig in das /tmp-Verzeichnis ein Unterverzeichnis mit den eigenen Fifo-Files. Über diese Files findet die gesamte Komunikation der einzelnen Musik-Programme statt, die mit Jack arbeiten.

Liegen jetzt diese Fifos auf der Festplatte, so werden bei jeder einzelnen Kommunikation Daten auf die Festplatte geschrieben, um dann gleich wieder von einem anderen Programm gelesen zu werden. Ihr könnt Euch nun vorstellen, daß diese Art der Kommunikation sehr langsam ist, und wenn das Ganze nicht irgendwie über Festplatten-Caches abläuft, dann ist von dem Hörgenuss wegen der hohen Latzenzzeiten nicht mehr viel übrig.


Man kann Jack jedoch sagen, daß er ein Temp-Verzeichnis in einer RAM-Disk verwenden soll. Dadurch wird die Kommunikation erheblich beschleunigt und man kommt in Latenzbereiche von etwa 16 Frames/Period (Hier: 0.6ms).


Für diejenigen unter uns, die JACK kompilieren, ist der Weg einfach:
1. JACK-TMP-Verzeichnis /jack-tmpfs anlegen
2. in der /etc/fstab folgenden Eintrag schreiben:
none /jack-tmpfs tmpfs defaults 0 0
3. mount -a eingeben

4. im Source-Verzeichnis von Jack folgende Zeile zum Konfigurieren/Kompilieren eingeben:
./configure --with-default-tmpdir=/jack-tmpfs && make -j2 && make test && make install
5. JACK starten und genießen.


Leider habe ich noch keine Möglichkeit gefunden, wie man dem jackd beim Starten das tmpfs als Option mitgeben kann und somit das Kompilieren überlfüssig ist.

Vielleicht probiert jemand mal aus, ob man mit den beigelegten Sourcen JACK neu kompilieren und trotzdem alle Audio-Programme noch mit JACK zusammen arbeiten... ( bei mir ist eh alles selbstkompiliert )


Ich hoffe, daß ich damit helfen konnte.

Viel Spaß weiterhin,
Gruß Lev

hmmmm... bisschen merkwürdig. Eigentlich sind seit vielleicht einem Jahr sämtliche jackd-binaries für RAMFS Temp gebaut - zumindest in UBUNTU und auch in Suse wird das sowieso Staandardmässig angelegt.
Beim Selberbauen sollte man natürlich darauf achten (ist aber glaub ich inzwischen die default-Einstellung in configure).

Die Latenz auf meinem Dapper-System ist inzwischen bei 5.8ms für den Standardbetrieb, mit etwas Vorsicht kann ich den Laden auch mit 1.4 ms betreiben. Experimentell (ein einfacher Synth bei 96000 Abtastrate) geht es auch bis 0.6 runter

Hi Zett,

Eigentlich sind seit vielleicht einem Jahr sämtliche jackd-binaries für RAMFS Temp gebaut - zumindest in UBUNTU und auch in Suse wird das sowieso Staandardmässig angelegt.

ist denn dann auch das RAMFS-Verzeichnis wirklich als RamFS gemountet? Das könnte nämlich der Dreh- und Angelpunkt dann sein.

Übrigens: Die 0.6ms habe ich bei einer Samplingrate von 48kHz.
Meine Jack-Sourcen sind etwa ein 3/4 Jahr alt. Vielleicht sollte ich mal updaten ...


Alles Gute weiterhin,
Gruß Lev

Leverator hat geschrieben:Hi Zett,
ist denn dann auch das RAMFS-Verzeichnis wirklich als RamFS gemountet?

Um ganz ehrlich zu sein: ich bin nicht sooo sicher. df -h zeigt mir die Auslastung des RAMFS an (also ist es wohl verfügbar) in fstab steht aber nichts von RAMFS. Fest steht nur, das in /tmp keine Einträge von jack auftauchen...

Leverator hat geschrieben: Übrigens: Die 0.6ms habe ich bei einer Samplingrate von 48kHz.

Das wären dann ganze 16 frames/buffer javascript:emoticon(':shock:')
RT-Kernel richtig ?

Leverator hat geschrieben: Meine Jack-Sourcen sind etwa ein 3/4 Jahr alt. Vielleicht sollte ich mal updaten ...

Denke schon, andererseits: wenns läuft

Das wären dann ganze 16 frames/buffer RT-Kernel richtig ?

RT-LSM um genau zu sein.

Aber bis jetzt funkioniert alles eigentlich ganz gut. Ich werde wohl erst dann mein System updaten, wenn Muse in 1.0 herauskommt und Etch released ist.
In der Zwischenzeit werde ich vielleicht noch Studio64 ausprobieren. Mal schau'n.


Lieben Gruß,
Lev