Rui Nuno Capela wrote:
Tim Goetze wrote:
>> I was told to revert to 22.214.171.124 (not possible in my specific
>> case, but there you go), in this list. Or to join the tuner's list.
> worked for me. Applied cleanly and compiled well after turning off
> some RCU-related preemption options that caused compilation errors,
> but I was in no mood to find out the exact how and why. So far, it
> has collected a few hours of solid uptime too, but I haven't done
> any latency measuring.
Update: on my laptop, the patched 126.96.36.199 kernel boots into an
endless list of tracebacks on the console. On the main box, USB
MIDI input is only read as soon as a key is pressed on the USB
keyboard (the one with the letters, not the MIDI one ...). USB MIDI
out is broken, too. So it's back to the old version.
ah, it seems i'm not alone.
hehe , nice try. We won't let you go that easily ;)
i'm currently recovering myself from schock
after returning from
vacation and while trying 2.6.26.x-rt for the rentrýe it all seemed
to work fine except omg... midi timing is a wreck, specially wrt.alsa
sequencer. event delivery is completely fubar. i mean, completely.
true showstopper, whatever :(
cacophony seems to be the right word to express
what it is.
however, didn't had the time to check whether
NOHZ is at stake. i'm
certainly going back to 2.6.25.x-rt where things are still sane and
pleasant for a while.
btw, having NOHZ=y (aka tickless kernel) has been
the norm here,
since its inception
CONFIG_NO_HZ=y - same norm here; with good results iff it works.
just tested 188.8.131.52-rt3 here with NO_HZ not set in my (old) pentium4
it just confirmed that NO_HZ is not the culprit here. midi events are
still being delivered *completely* out of time and the funny thing is it
just gets somewhat better whenever you hit the pc-keyboard keys.
however, it all gets back to badness once you stop pressing any key (eg.
another funny thing goes that on a core2 duo T7200 laptop (x86_64) the
same kernel config it runs all fine (NO_HZ=y)