erstens ist es nicht nur ein patch sondern sehr viele rt-patches, und zweitens werden diese patches schon seit geraumer zeit nach und nach in den vanilla kernel aufgenommen. nach meinem kenntnis stand wird zur zeit noch kräftig daran gearbeitet, die patches noch granularer zu machen und damit eine aufnahme in den vanilla kernel zu vereinfachen. viele infos darüber kannst du auch bei http://www.osadl.org finden, bzw. in der mailing liste von rt-linux.
Zitat: "Allerdings sind Abweichungen nach oben möglich, und es kann kein Maximum garantiert werden. Aus diesem Grund setzen Musikproduzenten und andere Anwender auf Kernel mit dem Echtzeit-Präemptions-Patch, der aber noch nicht in den offiziellen Kernel integriert wurde."
Diese Aussage ist so mMn falsch. Man _kann_ unter Linux Musik produzieren, aber nahezu 100% aller Musikproduzenten tun dies nicht. Und diese verwenden zwei Betriebssysteme, die auch keine maximale Latenz garantieren können, und bei denen man auch keinen Kernel-Patch einspielen kann.
Linux bietet hier also ein gutes zusätzliches Feature, das aber nahezu 100% aller Musikproduzenten nicht zu benötigen glauben. Auch ein ungepatchter moderner Linux-Kernel liegt heute bei den Audio-Latenzen schon auf Windows-Niveau. CoreAudio ist evtl. noch einen Tacken schneller.
Das Problem ist nicht mehr der Kernel, meiner Meinung nach, sondern einfach die Hersteller der Audiosoftware wie Steinberg etc. Diese Hersteller, genauso wie zB die Computer-Spiele-Industrie sehen Linux nicht als Markt, mit dem man Geld verdienen kann, unabhängig davon, das es mit Linux genauso gut geht, wie mit den anderen großen Playern.
Sehe ich ja genauso. Wobei die grundsätzlichen Fähigkeiten der Linux-Apps auch schon toll sind, aber irgendwie ist da vieles noch nicht rund. Das ist aber kein Vorwurf.
Worum's mir ging: "Musikproduzenten" beschreibt ja eine Anwendergruppe. Der Artikel suggeriert dann, dass diese Anwendergruppe den Kernel patchen muss, damit sie sinnvoll mit Linux arbeiten kann. Das stimmt aber schlichtweg nicht. Heute spielt man als Musikschaffender die RT-Patches aus Gewohnheit ein oder weil man etwas schon mehr als ausreichendes noch weiter verbessern möchte oder weil die Audio-Distri die eh schon drin hat, aber _nicht_ weil man sie unbedingt benötigt.
Von ich sehe kosten am Di, 22. Januar 2008 um 17:16 #
die audiosoftwarehersteller hätten schon längst Linux apps entwickelt, wenn die schnittstellen und die prerequisites auf den Linux maschinen standardisiert wären.
da dies nicht der fall ist, wären einerseits die entwicklungskosten aber noch viel schlimmer die supportkosten unermesslich hoch.
solange die LSB sich in diesem schneckentempo weiterentwickelt wirds auch nicht besser.
Von besserwisser am Mi, 23. Januar 2008 um 00:42 #
was brauchen die denn außer jack? Der Jack Soundserver ist doch eine fantastische Sache und heutzutage schon der inoffizielle Standard unter Linux-Audiosystemen
Der gepatchte Linxkernel bietet auf einem MittelklassePC in etwa die Latenzen, die man von einem MAC aus der gehobenen Liga erwarten darf. Stabiles Arbeiten bei um die 8ms, mit etwas Vorsicht geht es bis 1.5 ms 'runter.
>Man _kann_ unter Linux Musik produzieren, aber nahezu 100% aller Musikproduzenten tun dies nicht.
Sie tun das nicht, weil sie umlernen müssten - nicht, weil es nicht möglich wäre. Man muss auch einen Unterschied machen: wenn "Musikproduzent" jemanden meint, der/die zum Broterwerb täglich Musik produziert, dann werden sich allerdings nur sehr wenige finden, die Linux verwenden. 100% ist allerdings falsch:
Wenn ein "Musikproduzent" jemand ist, der/die einfach nur Musik produziert, wird es sicher ein paar mehr Leute geben, die Linux benutzen. Ein Studio, dass es sich leisten kann, künstlerisch orientiert und wählerisch zu sein, kann auch heute schon mit Linux arbeiten.
Wäre es eigentlich erstrebenswert, daß generell alle Linux-User (nachdem alle rt-Patches im offiziellen Kernel sind) einen Kernel mit Realtime Funktion auch auf ihren Desktop Systemen haben und Linux damit generell zum RT-OS wird? Oder hätte das Nachteile?
Ja das hätte Nachteile. Du brauchst keine Echtzeit, es sei den dein Linux hat was mit der Bremsanlage deines Wagens zu tun, zb. Realtime würde auf dem Desktop ganz klar Nachteilig sein, da einiges langsamer laufen würde.
Ich finde, die rt-Patches sollen auf jeden Falll in den Kernel. Und via Bootparameter kann dann jeder entscheiden, Realtime oder nicht. Das wäre cool.
Nach 20 min. suchen im make menuconfig habe ich nichts gefunden das mit latency zu tun haben koennte. Daher habe ich es einfach mal in der .config angehaengt echo CONFIG_LATENCYTOP=y >> .config
Nach einem make ist der Eintrag aber nicht mehr in meiner .config vorhanden. Auch wenn ich den gepachten Kern starte und einen zcat /proc/config.gz | grep LATENCYTOP
Das Ding ist im Moment ein _externer_ Patch, da das etwas "komische" latency annotations macht, die leicht kontrovers sein können, da andere Infrastruktur (oprofile etc.) sowas schon ähnlich anbietet.
Bei mir stehts unter: Kernel hacking -> Latency measuring infrastructure
Im Patch steht in "Kconfig.debug" ein "depends on SCHEDSTATS" und das wird mit Kernel hacking -> Kernel debugging -> Collect scheduler statistics eingeschaltet, das also vorher einschalten, sonst sieht man obigen Eintrag gar nicht.
Nun booten und tut aber erstmal trotzdem nix ... (cat /proc/latency_stats zeigt immer nur eine Zeile mit Latency Top version : v0.1)
Man muss noch echo 1 > /proc/sys/kernel/latencytop ausführen (oder mit sysctl kernel.latencytop auf 1 setzen).
Danach gabs auch von "latencytop" die erwünschten Infos. Vielleicht hilfts ja noch ...
Diese Aussage ist so mMn falsch. Man _kann_ unter Linux Musik produzieren, aber nahezu 100% aller Musikproduzenten tun dies nicht. Und diese verwenden zwei Betriebssysteme, die auch keine maximale Latenz garantieren können, und bei denen man auch keinen Kernel-Patch einspielen kann.
Linux bietet hier also ein gutes zusätzliches Feature, das aber nahezu 100% aller Musikproduzenten nicht zu benötigen glauben.
Auch ein ungepatchter moderner Linux-Kernel liegt heute bei den Audio-Latenzen schon auf Windows-Niveau. CoreAudio ist evtl. noch einen Tacken schneller.
Trotzdem naturlich ein gutes Tool von Intel.
Nur meine Meinung.
Gruß
A
Worum's mir ging: "Musikproduzenten" beschreibt ja eine Anwendergruppe. Der Artikel suggeriert dann, dass diese Anwendergruppe den Kernel patchen muss, damit sie sinnvoll mit Linux arbeiten kann. Das stimmt aber schlichtweg nicht. Heute spielt man als Musikschaffender die RT-Patches aus Gewohnheit ein oder weil man etwas schon mehr als ausreichendes noch weiter verbessern möchte oder weil die Audio-Distri die eh schon drin hat, aber _nicht_ weil man sie unbedingt benötigt.
da dies nicht der fall ist, wären einerseits die entwicklungskosten aber noch viel schlimmer die supportkosten unermesslich hoch.
solange die LSB sich in diesem schneckentempo weiterentwickelt wirds auch nicht besser.
Der Jack Soundserver ist doch eine fantastische Sache und heutzutage schon der inoffizielle Standard unter Linux-Audiosystemen
>Man _kann_ unter Linux Musik produzieren, aber nahezu 100% aller Musikproduzenten tun dies nicht.
Sie tun das nicht, weil sie umlernen müssten - nicht, weil es nicht möglich wäre. Man muss auch einen Unterschied machen: wenn "Musikproduzent" jemanden meint, der/die zum Broterwerb täglich Musik produziert, dann werden sich allerdings nur sehr wenige finden, die Linux verwenden. 100% ist allerdings falsch:
Studio mit Linux als HD-Recorder
Wenn ein "Musikproduzent" jemand ist, der/die einfach nur Musik produziert, wird es sicher ein paar mehr Leute geben, die Linux benutzen. Ein Studio, dass es sich leisten kann, künstlerisch orientiert und wählerisch zu sein, kann auch heute schon mit Linux arbeiten.
Ich finde, die rt-Patches sollen auf jeden Falll in den Kernel. Und via Bootparameter kann dann jeder entscheiden, Realtime oder nicht. Das wäre cool.
VG
A
Ich habe folgendes gemacht:
latencytop-0.3.tar.gz ausgepackt und uebersetzt.
Einmal zur Probe das Programm laufen lassen
./latencytop
Please enable the CONFIG_LATENCYTOP configuration in your kernel.
Exiting...
Ok alles klar na dann auf zum Kern.
Kernbesorgt und ausgepackt
tar xjf linux-2.6.24-rc8.tar.bz2
Danach den patch besorgt und die sourcen gepached
cat latencytop.patch | patch -p0
patching file linux-2.6.24-rc8/arch/x86/kernel/stacktrace.c
patching file linux-2.6.24-rc8/fs/proc/base.c
patching file linux-2.6.24-rc8/include/linux/latencytop.h
patching file linux-2.6.24-rc8/include/linux/sched.h
patching file linux-2.6.24-rc8/include/linux/stacktrace.h
patching file linux-2.6.24-rc8/kernel/Makefile
patching file linux-2.6.24-rc8/kernel/fork.c
patching file linux-2.6.24-rc8/kernel/latencytop.c
patching file linux-2.6.24-rc8/kernel/sched_fair.c
patching file linux-2.6.24-rc8/kernel/sysctl.c
patching file linux-2.6.24-rc8/lib/Kconfig.debug
Nach 20 min. suchen im make menuconfig habe ich nichts gefunden das mit latency zu tun haben koennte. Daher habe ich es einfach mal in der .config angehaengt
echo CONFIG_LATENCYTOP=y >> .config
Nach einem make ist der Eintrag aber nicht mehr in meiner .config vorhanden.
Auch wenn ich den gepachten Kern starte und einen
zcat /proc/config.gz | grep LATENCYTOP
ausfuehre gibt es keinen Treffer.
Kann mir einer sagen woran es liegen koennte?
Kernel hacking -> Latency measuring infrastructure
Im Patch steht in "Kconfig.debug" ein "depends on SCHEDSTATS" und das wird mit
Kernel hacking -> Kernel debugging -> Collect scheduler statistics
eingeschaltet, das also vorher einschalten, sonst sieht man obigen
Eintrag gar nicht.
Nun booten und tut aber erstmal trotzdem nix ...
(cat /proc/latency_stats zeigt immer nur eine Zeile mit
Latency Top version : v0.1)
Man muss noch
echo 1 > /proc/sys/kernel/latencytop
ausführen (oder mit sysctl kernel.latencytop auf 1 setzen).
Danach gabs auch von "latencytop" die erwünschten Infos.
Vielleicht hilfts ja noch ...