Der JACK-Dienst ist notwendig, um in einen virtuellen Musikstudio Audio- und MIDI-Daten zwischen Anwendungen und Hardware umherzurouten. Um in Echtzeit auf die Soundkarte zugreifen zu können, sind spezielle Treibereinstellungen bei meiner Soundkarte nötig, um eine störungsfreie Wiedergabe zu ermöglichen – doch was für Störungsfreiheit im Echtzeitbetrieb sorgt, provoziert unklaren Ton bei der herkömmlichen Ton-Ausgabe – z.B. unter KDE bei laufendem ARTS-Daemon.
Von daher wäre es eigentlich sinnvoll, wenn die Tonausgabe prinzipiell über den Jack-Daemon erfolgt, doch dieser wird manuell gestartet und wenn KDE so konfiguriert ist, daß die Tonausgabe prinzipiell über JACK laufen soll, erfordert dies, daß der Jack-Dienst beim Hochfahren von KDE bereits gestartet ist.
Der JACK-Daemon wird grundsätzlich ohne Runlevel-Skripte ausgeliefert und ich weiss nicht, ob es dafür sogar einen Grund gibt. Ich überlege mir, ein solches Runlevelskript zu schreiben, frage mich aber ob es nicht eine sinnigere Lösung gibt.
Alles, was man von Hand starten kann, kann man im Prinzip auch über ein Startskript in einem der Runlevel starten lassen. Die Frage ist hierbei nur, in welcher Reihenfolge die Dienste sinnvollerweise gestartet werden. Da ich mit JACK noch nichts zu tun hatte, kann ich dir über dessen spezielle Befindlichkeiten, was die Startreihenfolge angeht, allerdings nichts sagen.
Günter
Im Kofler Buch Linux, Kapitel Init-V-Prozess steht dazu einiges. Unter /etc/init.d oder /etc/rc.d/init.d stehen die Skripte. Dort müßte das Script hin (rc.5/K99myscript). Oder man findet heraus, ob es auch geht durch manuelles stoppen und starten (z.B. /etc/init.d/http stop). Es ist auch möglich sich einen eigenen komplett neuen weiteren Runlevel zu bauen.
Wie Runlevel-Skripte an sich funktionieren war nicht die Frage. Ich habe schon einige geschrieben und klar lässt sich darüber alles starten. Die Frage ist nur, ob es Sinn macht.
Fährt man den Rechner hoch, wird zu erst die /etc/inittab abgearbeitet, dann die Runlevel-Skripte ausgeführt. Bei einem Desktop-System werden mit dem Start des X-Servers weitere Prozesse ausgeführt und KDE/Gnome starten auch noch einmal eigene Dienste. Kommt man dem Start eines Dienst eines Desktop-Systemes mit einem Runlevel-Skript zuvor, so kann das die fehlerfreie Funktion beeinträchtigen. KDE startet z.B. den ARTS-Daemon, der mit JACK nicht kompatibel ist. Das grafische Jack-Starttool qjackctl killt den Arts-Prozess beim Start und startet ihn wieder beim Beenden von Jack. Ist Jack vor dem Start von KDE gestartet, kann ARTS nicht gestartet werden. Es gibt eine Fehlermeldung und die KDE-Anwendungen haben keinen Sound. Darum ist einwenig mehr zu tun, als nur ein Runlevel-Skript zu schreiben. Und da ist eine elegante Lösung gefragt.
Da ich Jack noch nicht benötigt und auch keine Verwendung dafür
(momentan) habe:
Was passiert wenn du Jack nach dem Start von KDE und arts per
~/.kde/Autostart/autostart,sh startest?
Probier mal aus.
Ich habe im Support-Channel der Jacklab-Distribution nachgefragt (auch wenn ich Jacklab nicht nutze). Die Leute meinten, daß KDE und Arts zwar eine Option kennen, um die Ausgabe an Jack umzulenken, diese aber ohne Funktion sei (nicht fertig). ARTS wird nicht mehr weiterentwickelt, da es für KDE4 was neues (Phonon) gibt.
Für Jack gibt es bewusst kein Runlevel-Skript, da der Dienst nur dem Benutzer zur Verfügung steht, der ihn nutzt. Das heisst, wenn der Dienst als root gestartet ist, müssen sämtliche Musikprogramme auch als root ausgeführt werden.
Das Problem habe ich nun so gelöst, daß das Startskript für den Jack-Dienst den Soundtreiber mit anderen Optionen neu lädt, bevor der eigentliche Dienst gestartet wird. Keine sinnvolle Lösung, aber funktioniert. Mit KDE4 ist das Problem ohnehin gelöst. Phonon ist in der Lage, die Audio-Daten an Jack zu übergeben.
Statt dem Soundtreiber den Parameter position_fix=3 //fifo zu setzen sollte ich einmal ausprobieren, das eigentliche Modell mit anzugeben (model=xxx). Der Treiber snd_hda_intel erkennt das eigentliche Modell nicht immer richtig. wenn ich model=macbook angebe, läuft allerdings garnichts.
