Echtzeit mit JACK?

[kebjoern]

Hallo Forum,

Ich glaube ich habe alles abgegrast, was irgendwie mit Jack zu tun hat, viele Sachen habe ich schon mehrfach durchforstet um zu gucken, was ich noch probieren kann, inzwischen sehe ich in Euch meine letzte Hoffnung.

Ich möchte gerne JACK benutzen, um verschiedene Audioprogramme gleichzeitig verwenden zu können. Habe mir dazu extra einen Kernel gebaut und ein realtime-lsm und die alsa-Treiber als Module dazu. Der Kernel läuft, soweit ich das beurteilen kann wunderbar, das realtime Module ist auch da und die Alsa-Treiber auch - nur JACK will nicht laufen.

Rufe ich qjackctl unter x auf bekomme ich eine ganze Reihe von folgenden Meldungen:

delay of 46337.000 usecs exceeds estimated spare time of 23159.000; restart ...

Starte ich jackstart als root aus der Konsole, meldet JACK, nach 5 Sekunden:

jackd watchdog: timeout - killing jackd

In watchdog hab ich mich noch nicht reingelesen, aber das hier hab ich gefunden:

Currently (as of 2.6.7) JACK has a serious problem creating SCHED_FIFO threads for real-time processing. It is unclear whether this is a bug in JACK, in the new Native PThreads Library (NPTL), or in the 2.6 kernel. At the moment no one has a solution, but there is a workaround: define LD_ASSUME_KERNEL=2.4.19 in the environment of the jackd process and of every JACK client. The easiest way to do this is setting it in ~/.profile , or wherever you customarily define global environment variables. Glibc developer Ulrich Drepper explains the operation of LD_ASSUME_KERNEL in more detail.

Die ~/.profile-Datei habe ich nicht gefunden. Mit Umgebungsvariablen habe ich nocht nicht gearbeitet. Kann ich damit das Problem lösen? Wenn ja, wo setzte ich in Debian normalerweise die globalen Umgebungsvariablen?

Oder ist am Ende meine Mühle einfach nur ein bischen zu lahm (AMD Athlon:1000 Mhz, Soundcarte: Aureon Fun 5.1 mit AC´ 97: C-Media Electronics Inc. CM8738, 256 MB RAM[ganz schön wenig, oder?])?

Ich danke Euch schon mal und hoffe, dass Ihr mir helfen könnt

Björn

P.s. Kernel: 2.6.18, Etch

[ReelOberon]

Hallo

Die ~/.profile-Datei habe ich nicht gefunden. Mit Umgebungsvariablen habe ich nocht nicht gearbeitet. Kann ich damit das Problem lösen? Wenn ja, wo setzte ich in Debian normalerweise die globalen Umgebungsvariablen?

Du solltest zuerst einmal diene persönlichen Umgebungsvariablen ausprobieren, bevor du Dich an die globalen heranwagst.
Deine persönlichen Variablen stehen in "~/.profile" d.h. "/home/<Benutzername>/.profile". Du kannst die Datei daher nur sehen, wenn Du in KDE, Gnome etc. 'unsichtbare Dateien anzeigen' oder etwas äquivalentes angewählt hast.
Diese Datei wird nicht vom System angelegt und muss selbst erzeugt werden. Das geht mit jedem Texteditor. In diese Datei trägst Du die Variablen versuchsweise ein. Dann musst Du Dich neu einloggen um die Variablen zu nutzen.
Wenn alles funktioniert kannst dasselbe in "/etc/profile" als root eintragen und die eigenen Eintragungen nach gusto löschen oder lassen. Ab dann gelten die Variablen für alle Benutzer, die sich neu einloggen. Ausnahmsweise ist hier auch unter Linux einmal ein Neustart des Systems (reboot) sinnvoll.
PS in ~/.profile~ alles eintragen das nur für einen selbst gelten soll. Ein weiterer Vorteil ist, das man keine rootrechte benötigt.
best regards

[kebjoern]

Das mit der ~/.profile Datei hab ich versucht: hat nichts gebracht. Gibts jemanden, der jack in testing verwendet?

[gms]

Hi kebjoern,

Ich habe das Echtzeitverhalten zwar nur kurz angetestet, doch Prinzipiell hat es bei mir mit dem 2.6.20-rc6 funktioniert. Ich habe nur ein Problem dabei, daß es einen Konflikt zwischen diesem Patch und dem nvidia-Treiber gibt, bei mir gibts daher leider nur ein entweder Realtime oder NVIDIA 3D Acceleration. Ich habe das Modul zwar auch mit gebaut, habe es dann aber nicht benötigt, sondern den Lösungsweg über PAM und die limits.conf gewählt

Gruß
gms

[kebjoern]

PAM? limits.conf? was ist das? Geht das auch mit einem selbstcompilierten 2.6.18 Kernel? Wie kann ich realtime testen?

Tut mir leid, dass ich Dich so mit Fragen bombadiere, aber ich bin gerade um alles froh, was mich weiter bringt.

Danke!

Björn

[gms]

Ich habe so wie du den realtime-preempt Patch eingespielt.
Beim "Einrichten" habe ich mich an diesem How-To Orientiert
http://proaudio.tuxfamily.org/wiki/inde ... _RT_Kernel
In diesem How-To werden diesbeüglich mehrere Möglichkeiten angeboten
a) realtime-lsm (deprecated)
b) RLIMITS with PAM
c) RLIMITS without PAM

Ich habe die Methode "RLIMITS with PAM" gewählt und mußte daher nur die folgenden Zeilen in die Datei "/etc/security/limits.conf" rein kopiert.

Code: Alles auswählen

# rtprio
@audio - rtprio 90
@audio - nice -5
@audio - memlock 500000

(Die Schritte mit "equery which pam" und "emerge -av gentoolkit" brauchst du auf einem Debiansystem nicht)

Damit war dann auch schon Jack ( über qjackctl ) einsatzbereit

Gruß
gms

[goecke]

ich benutze nur den Realtime-patch
( http://people.redhat.com/mingo/realtime-preempt/ ) im 2.6.19.1-rt14 kernel

und starte jack via sudo von hand

Code: Alles auswählen

sudo jackd -R -P 70 -d alsa -d hw:1,0 -r 44100

und benutze ecasound für Aufnahmen :

Pegel-Anzeige

Code: Alles auswählen

sudo ecasignalview -i jack_alsa -f:f32_le,2,44100

und Aufnahme

Code: Alles auswählen

sudo ecasound -f:f32_le,2,44100 -i jack_alsa -o outputfile.wav

Die Aufnahme mache ich 32-bit format (meine Karte kann 24 bit) sonst statt "f32_le" "16" verwenden.
ggf. reicht Dir das schon aus - bei mir funktioniert es so ohne nennenswerte Probleme.


der Vorteil ist, dass es so komplett ohne X funktioniert ( gms schrieb er habe probleme mit nvidia => kein X kein Konflikt)

den anderen Link muss ich mir nochmal genauer durchlesen.
mit RTLimits das klingt interessant

gruss
Johannes

[gms]

der Vorteil ist, dass es so komplett ohne X funktioniert ( gms schrieb er habe probleme mit nvidia => kein X kein Konflikt)

das ist eigentlich mehr ein Lizenz-Problem als ein technisches. Der Patch "redefined" die inline Funktion "pagefault_disable". Diese kann normalerweise von properitären Treibern verwendet werden und wird auch indirekt vom nvidia Treiber verwendet ( von pte_offset über kmap_atomic ). Das Problem ist nun, daß der Patch diese Funktion nur als EXPORT_SYMBOL_GPL ( also nur für GPL Code ) exportiert und daher vom nvidia-Treiber nicht mehr verwendet werden kann.
Ich habe dieses Verhalten, als Bug interpretiert und (für mich) einen Patch für den Patch geschrieben, der diesen Konflikt auflöst. Auch wenn properitäre Treiber, die im Kernelspace laufen, in jedem Fall keine sauber Lösung sind, bewege ich mich damit allerdings (leider) in einer Grauzone.

[edit]
Nachtrag für alle die diesen Patch zusammen mit dem nvidia-Treiber bauen möchten:
@zander (NVIDIA Corporation) ein guter Mann vom nv News Forum ( http://www.nvnews.net/vbulletin/ )
hat mich darauf aufmerksam gemacht, daß der nvidia Treiber diese Funktion nur benötigt, wenn CONFIG_HIGHPTE eingeschaltet ist. Dieses abzuschalten ist daher die sauberste Lösung ( von mir bereits erfolgreich getestet )
[/edit]



aber zurück zum Thema:
durch die RTLimits ersparst du dir das "sudo" und gibst stattdessen der User "audio" die entsprechenden Rechte.
Das ist allgemein, aus Security-Sicht betrachtet, etwas besser, weil jackd nicht mehr unter "root" laufen muß. Andererseits können diese Limits aber auch von allen Membern der "audio" Gruppe für "nicht audio" Zwecke mißbraucht werden. Beide Lösungen haben daher ihre Vor- und Nachteile.
Paranoide Wesen sollten daher eine Kombination wählen, bei der ein Systemuser z.B. "audiojack" die Rechte über PAM bekommt, und die Member der "audio" Gruppe den "jackd" über "sudo" unter dem Useraccount "audiojack" starten können.

Gruß
gms

[finupsen]

Code: Alles auswählen

# rtprio
@audio - rtprio 90
@audio - nice -5
@audio - memlock 500000

goldwert ! Hat bei mir nach einem kernel-update wunderbar geklappt ... tnx

[kebjoern]

Hm! Bei mir klappts nicht. Kann es sein, dass das realtime-lsm mehr stört, als dass es hilft?

Irgendwie hab ich das alles noch nicht ganz kappiert:
Ich habe mir den Kernel gebaut, um realtime-lsm als Modul verwenden zu können. Jetzt lese ich, dass das veraltet ist. Was ist dann die aktuelle Methode? Der Patch?

Kann ich u.U. mit Pam noch irgendwas drehen? Ich habe versucht

# rtprio
@audio - rtprio 90
@audio - nice -5
@audio - memlock 500000

in /etc/security/limits.conf zu schreiben. Als das nichts gebracht hat, habe ich zusätzlich in /etc/pam.d/su die Zeile

Code: Alles auswählen

session required pam_limits.so 

auskommentiert - hat auch nichts gebracht. Weiter bin ich noch nicht gekommen.

goldwert ! Hat bei mir nach einem kernel-update wunderbar geklappt ... tnx

finupsen, hast Du einen Standard-Kernel verwendet?

Danke!

Björn

[finupsen]

> finupsen, hast Du einen Standard-Kernel verwendet?

Ja, den aus testing 2.6.18+5. Ich habe realtime-lsm (pakete und module) wieder komplett entfernt und
CONFIG_SECURITY_CAPABILITIES wieder fest im kernel. Also im prinzip so, wie das kernel original
ausgeliefert wird ...