Ubuntu Dapper Drake - übertrifft meine Erwartungen

[zettberlin]

-Apps wie MusE und Rosegarden scheitern an der realtimeclock

Das trifft nur auf die vorkompilierten Pakete aus universe zu - ich habe beide selber kompiliert und beide funktioniern sehr gut in meinem Standard-Dapper.
Beide haben auch einige Bugs (Noteoff-Schwierigkeiten in Muse, Ungereimtheiten bei den dssi-synth-Schnittstellen in RG - keine Showstopper)

Für Menschen, die keine Lust haben auf selbstkompilieren haben werde ich einen vorkompilierten vanilla Kernel mit allen fixes (snd-seq wird eingebunden, rtc richtig, rt-lsm und rt patch)- wenn alles gutgeht - demnächst für ubuntu zum Download zur Verfügung stellen.

Super-cool
Meinst Du, das Dana und Du das als Paket in universe unterbringen können?

[zettberlin]

Folglich juckt's mich schon in den Fingern, auf eine der genannten Kandidaten zu wechseln - erst recht wenn Dapper schon ganz gut mit Audio funktioniert. (Ich weiß - kein vergleich zu einem echten rt-system, aber wer weiß ob ich das a) wirklich brauche und b) ob der Kernel von Ubuntu nicht von Haus aus irgendwann noch besser für Audio taugt.)

Probier´s einfach mal aus - ich bin sehr glücklich damit - es wurmt mich zwar, das ich mit einem rt-kern noch mehr herausholen könnte aber so wie ich arbeite (HD-Recording und Offlinekomponieren mit Synths und Samplern), stosse ich nicht an Grenzen, die mit dem rt-patches nicht da wären.

[metasymbol]

Super-cool
Meinst Du, das Dana und Du das als Paket in universe unterbringen können?

Auf gar keinen Fall - das wird ein heftig experimenteller Kernel zum Testen, der enhält kein einziges der Patches von Canonical Ltd (config wird aber geclont) und ich bin auch nicht fähig, die Postinstallationsscripte für zB initrd anzubieten. Dafür braucht es einen richtigen Kernelhacker, der mit deb vertraut ist.

Aber ich werde dazu eine kleine Anleitung schreiben wie man selbst eine initrd erstellt und einen alternativen Grubeintrag, und mit etwas Glück läuft auch deine Hardware, aber evtl so Sachen wie automatisches Einbinden von usb sticks/cdrom oder acpi-features, sowie vmware modul unterstützung und andere Probleme, die von propritären Treibern herühren, wie nvidia und ati Karten etc. wird es geben. Das weiss ich jetzt noch nicht, aber dir werd ich als erster Bescheid geben incl downloadlink.

Und was module für propritäre Treiber betrifft hab ich im ubuntuforum einen prima Tipp gefunden -> http://www.ubuntuforums.org/showthread.php?t=204359 -so kanns funktionieren.

[metasymbol]

-Apps wie MusE und Rosegarden scheitern an der realtimeclock

Das trifft nur auf die vorkompilierten Pakete aus universe zu - ich habe beide selber kompiliert und beide funktioniern sehr gut in meinem Standard-Dapper.
Beide haben auch einige Bugs (Noteoff-Schwierigkeiten in Muse, Ungereimtheiten bei den dssi-synth-Schnittstellen in RG - keine Showstopper)

LOL Selberkompilieren als benutzerfreundliche Alternative... Ausserdem hast du schon bemerkt das das Timing jetzt grausam ist? (untight) Klar kann man die rtc optionen rausnehmen, aber die rtc wird als tick gebraucht und ohne verlässlichen tick auch kein verlässliches timing...

[zettberlin]

LOL Selberkompilieren als benutzerfreundliche Alternative...

Jedenfalls deutlich einfacher als den ganzen Kernel auszutauschen...

Ausserdem hast du schon bemerkt das das Timing jetzt grausam ist?

Ja - das ist ein echtes Problem - auch beim Offlinebertrieb, weil Loops nicht richtig rund laufen und Synchronisation Probleme macht. Ganz praktisch funktionieren Muse und RG aber durchaus - für Profibetrieb scheint es aber ohne eine tieferschürfende Lösung für die rtc-Angelegenheit in der Tat nicht zu gehen.
Wie ist es eigentlich, wenn man die Dinger wie früher setuid root laufen lässt?

[metasymbol]

Jedenfalls deutlich einfacher als den ganzen Kernel auszutauschen...

Was heisst austauschen: es würde reichen den ubuntukernel zu rebuilden aus den src-deb. Applikationen zu rebuilden ist hier Symptomdoktorei. Kernel zu rebuilden würde wenigstens die Ursache beheben und ist auch nicht schwerer als ein Programm zu rebuilden.

Wie ist es eigentlich, wenn man die Dinger wie früher setuid root laufen lässt?

Es geht darum, der die Systemechtzeitauflösung im Kernel auf 10ms oder ähnlich gestellt ist. Das ist sicher für Anwender, aber viel zu hoch für ein tightes timing mit Sequenzern. Da kann man gar nichts machen als mit "make menueconfig" die KernelKonfiguration zu verändern, auf am besten 1ms rtc.
Weil die Systemzeit gilt auch für root

[zettberlin]

Es geht darum, der die Systemechtzeitauflösung im Kernel auf 10ms oder ähnlich gestellt ist. Das ist sicher für Anwender, aber viel zu hoch für ein tightes timing mit Sequenzern.
...
auf am besten 1ms rtc.
Weil die Systemzeit gilt auch für root

Gibt es denn einen besonderen Grund, warum rtc nicht Standardmässig auf ein Tausendstel eingestellt ist?

[metasymbol]

Gibt es denn einen besonderen Grund, warum rtc nicht Standardmässig auf ein Tausendstel eingestellt ist?

Bestimmt weil Linus Thorwalds gesagt hat das man mit Linux eh keine Musik machen sollte - die kernelDevs haben uns nicht richtig lieb *buhuhuhu* immer wollen sie unsere Performance drosseln wegen blöder Sicherheitsaspekte *räbääääh* und uns zwingen zwischen Teufel MS und Bezelbub Apple zu wählen.

Mal ernsthaft. ich denke Sicherheit von Serversystemen steht bei Linux immer im Vordergrund, es wird ja eigentlich nur für Musik "Missbraucht". Deshalb wird es Zeit das jede ernstzunehmende LinuxDistribution optional einen "Musikkernel" anbietet. Das wird aber leider erst dann sein, wenn es um sehr viel Geld geht.

[zettberlin]

Das wird aber leider erst dann sein, wenn es um sehr viel Geld geht.

Oder wenn der Auffwand, so einen Multimediakernel zu bauen und zu betreuen gering genug wird. Wenn die Musikfreaks lange genug daran gearbeitet und getestet haben, wird das Teil leicht genug beherrschbar, das sich Novell, Mandriva und Co mit grosser Geste "Suupercooler neuer Multimediakernel - extra von uns für Sie entwickelt." auf die Boxen schreiben können.

[Drumfix]

Vorsicht! In nem PC gibt es

rtc = realtime clock, die die Zeit (im ausgeschalteten Zustand weiterlaufen lässt und auch ne Zusatzkomponenete enthält, mit der man periodisch
Interrupts erzeugen kann mit 256, 512, 1024Hz ...

system timer = Systemzeitgeber, der in älteren 2.6 Kerneln mit 1000Hz und
jetzt mit 100Hz betrieben wird.

Das Problem ist, dass Muse/Rosegarden die RTC Periode selbst einstellen
wollen, was aber nur für root erlaubt ist. Und wenn das nicht geht, eben
den Systemtimer benutzen (mit seinen 100Hz).

Eine vernünftige Lösung wäre, beim Bootprozess die Periode einzustellen
und Muse/Rosgarden die so eingestellte Periode einfach benutzen zu lassen.
Der schwarze Peter liegt also bei Muse/Rosegarden, nicht beim Kernel.

Bei gemischten Midi/Audiosetups empfiehlt es sich aber eh, die
Sequenzer per Jack synchronisieren zu lassen, da man mit RTC und
Sampleclock mal wieder das Problem zweier nicht synchronisierter
Clocks hat. Und dann sollte es dann wenigstens 44100/64 sein für
ne 1.5 ms Periode.

Gruss

[Drumfix]

kleine Anmerkung zum RTC Problem, da ich gerade die Suse 10.1 von
der CT Special Ausgabe installiert habe.

Als root einmal die Rechte für das RTC Device setzen:

chgrp audio /dev/rtc
chmod g+rw /dev/rtc

und nach dem Booten jeweils (als root) folgendes eingeben (/proc Pfad
habe ich gerade nicht genau im Kopf):

echo 1024 > /proc/devices/rtc/max-user-freq

Letztere Zeile kann man wohl auch in /etc/init.d/boot.local
eintragen, dann sollten die Sequencer korrekt funktionieren.

alles weitere bzgl Installation steht ja schon bei http://jacklab.net/userwiki/index.php/N ... eps_to_JAD

Die mitgelieferten Audioprogramme sind nicht gerade auf dem neuesten
Stand. Insbesondere hydrogen 0.9.2 hat nen üblen Bug:
Wenn man das Songfenster öffnet, geht die CPU Load auf 99%.

Mit dabei sind:
muse 0.7.2pre4
zynaddsubfx 2.2.1-15
fluidsynth 1.0.6-16
hydrogen 0.9.2-16
seq24 0.6.3-14
jamin 0.95.0-15
aeolus 0.3.1-16
jack 0.100.0-17
qjackctrl 0.2.19a-13
lash 0.5.0-13
sowie die cmt und swh ladspa plugins

Aber kein Ardour, Rosegarden, Linuxsampler, Hexter, Fst!

Auch mit den Realtimefähigkeiten des Standardkernels ist es nicht weit her.

Hilft also nur sich den RT-Kernel + Updates für die Programme vom
Jacklab Repository zu holen.

Kleines PS an metasymbol:

Wäre nett, wenn man auch jMax, pd und Supercollider ins Repository
aufnehmen würde. Bisschen mehr Modularsysteme könnte nicht schaden.

Gruss
Drumfix

[metasymbol]

Hi Drumfix,

Darüber hatte ich schon im JackLab Forum berichtet, was mit 10.1 geht (oder besser nicht geht)
Zukünftige JAD Kernel werden rtc probleme von der Wurzel her angegehn. Unser Hacker Appleonkel arbeitet greade an einem update, das soll dann auch rt-lsm enthalten.

Programme die du dir wünscht werden auch gebaut früher oder später, wenn du die im jl-forum postest. Mit pd haben wir bisher ein Problem wegen zu alter Libs (pd wurde anscheined ewig nicht mehr aktualisiert) - falls du eine Idee hast wie man das gebaut kriegst, admine ist über Tipps dankbar.

Am besten postest du das nochmal im JL Forum

[Drumfix]

Das aktuelle Pd-0.39-2 habe ich mir gerade gezogen, und mit

configure --prefix=/usr --enable-jack
make
make install

gebaut. No problems...

[metasymbol]

Das aktuelle Pd-0.39-2 habe ich mir gerade gezogen, und mit

configure --prefix=/usr --enable-jack
make
make install

gebaut. No problems...

Mkey, admine schaut sich das nochmal an dann dürfte ein RPM auch die nächste Woche dasein... Vielleicht haben wir da auch was verwechselt.... pd war bisher nicht die Applikation die angefragt wurde, zumal das Programm mE auch etwas sperrig ist

Glücklicherweise sitzt admine *gerade* neben mir

Aber solche Sachen sonst bitte im jl Forum weil das wird auch von allen aktiven jacklab membern gelesen.

[nowhiskey]

hi drumfix,

Vorsicht! In nem PC gibt es

rtc = realtime clock, die die Zeit (im ausgeschalteten Zustand weiterlaufen lässt und auch ne Zusatzkomponenete enthält, mit der man periodisch
Interrupts erzeugen kann mit 256, 512, 1024Hz ...

system timer = Systemzeitgeber, der in älteren 2.6 Kerneln mit 1000Hz und
jetzt mit 100Hz betrieben wird.

also ich benutze einen selbstgebastelten 2.6.16-rt13kernel, der auf 100Hz getaktet ist.
das wurde mir auf agnula-mailing-list so empfholen.
läuft auch alles gut, bis dass xmms damit nicht zurecht kommt, aber das kan auch daran liegen, dass auf meinem system gerade x11 noch nicht ap-to-date ist (6.9), so glaube ich dass xmms da ein problem hat.

aber der grund warum ich schreibe ist, was du darüber denkst, na über diese 1000Hz option?!

das config file sieht also an der stelle so aus:

# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000


gruss,
doc

p.s. ich finde wir brauchen mal langsam eine gesonderte "kernel" rubrik hier?
ist halt nicht gerade trivial da thema.