Jussi Laako wrote:
> Rui Nuno Capela wrote:
>> just tested 2.6.23.3-rt3 here with NO_HZ not set in my (old) pentium4
>> desktop.
>>
>> 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. shift-key)
>>
>> another funny thing goes that on a core2 duo T7200 laptop (x86_64) the
>> same kernel config it runs all fine (NO_HZ=y)
>
> I'm kind of wondering what these have in
> /sys/devices/system/clocksource/clocksource0/current_clocksource
>
a) on the desktop (p4(a)2.80C), where midi timing delivery is completely
broken:
# uname -a
Linux gamma 2.6.26.3-rt3 #1 SMP PREEMPT RT Sat Aug 23 19:34:05 WEST 2008
i686 i686 i386 GNU/Linux
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
b) on the laptop (core2@T7200), where midi seems to work fine:
# uname -a
Linux zeta 2.6.26.3-rt3 #1 SMP PREEMPT RT Sat Aug 23 19:14:58 WEST 2008
x86_64 x86_64 x86_64 GNU/Linux
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet
least to say, audio (ie. jackd) works fine on both cases. i've also
tried to set the clocksource to hpet in a) and got no change in midi/tty
brokenness.
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rui Nuno Capela wrote:
> Robin Gareus wrote:
>> Rui Nuno Capela wrote:
>>> Tim Goetze wrote:
>>>> [Tim Goetze]
>>>>
>>>>> [victor]
>>>>>> I was told to revert to 2.6.24.17 (not possible in my specific
>>>>>> case, but there you go), in this list. Or to join the tuner's list.
>>>>> http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.26.3-rt2.bz2
>>>>>
>>>>>
>>>>> 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 2.6.26.3 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 2.6.23.3-rt3 here with NO_HZ not set in my (old) pentium4
> desktop.
>
> 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.
> shift-key)
>
> another funny thing goes that on a core2 duo T7200 laptop (x86_64) the
> same kernel config it runs all fine (NO_HZ=y)
>
http://kerneltrap.org/Linux/Removing_the_Big_Kernel_Lock mentions TTY
drivers being a problem, actually "a long and difficult task"..
2c,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkixWYkACgkQeVUk8U+VK0KoDgCgrFy2K9eamJrZUOHbG3m4ZuIz
ypgAn36etP4eo/+I0mbnAO4BbX8kajgA
=B1I0
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey guys,
After bleeding-edge linux-tuning and some br0ken 2.6.25's what are
candidates for a stable audio setup?
I'm currently running "2.6.24.7-rt17-pure #3 SMP PREEMPT RT" from
http://guests.goto10.org/~krgn/files/ which seems great for day-to-day
work and sound-production. runs for 3 days now, few suspend to RAM, no
reboot since, and worked out of the box.
It passes the mplayer via wifi-NFS and jconv test without a single xrun
at 256 frames/period, 3period @ 48Ksps with HDA-intel/PCI and UA-25+USB.
JACK (ardour, rosegarden, etc) works as usual.. including
gnome,iceweasel+flash and whatever - gonna test firewire soon.
I'm considering to make this my new default; maybe recompile it with
few minor changes (optimized for MCORE2, no generic i386) - It also
seems to be a bit more power-hungry that 2.6.24.3-rt3 - hard to tell
since former kernel does support `powertop`:
(No detailed statistics available; please enable the CONFIG_TIMER_STATS
kernel options - This option is located in the Kernel Debugging section
of menuconfig which is CONFIG_DEBUG_KERNEL=y in the config file)
Just for reference it's a X60s, running a
debian-lenny/sid/debian-multimedia/64studio distro mix..
I changed the USB-irq in the bios but I didn't do much besides using
rtirq.deb from 64studio and usual limits.conf with debian jackd
0.109.2. - I still have `dev.rtc.max-user-freq=8192` in sysctl.conf -
but I don't think it is being used with HPET.
What kernel/setup/system are you guys *tuning* for work, recording,
production and/or live performance.
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkiqXOgACgkQeVUk8U+VK0LsLgCfa61CKCKoS/xFhaBxWzZRfS9A
fsUAn1ybxfn/P7fjiEr4WLijOXpcVM8r
=CH0l
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rui Nuno Capela wrote:
> Tim Goetze wrote:
>> [Tim Goetze]
>>
>>> [victor]
>>>> I was told to revert to 2.6.24.17 (not possible in my specific
>>>> case, but there you go), in this list. Or to join the tuner's list.
>>> http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.26.3-rt2.bz2
>>>
>>> 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 2.6.26.3 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.
I'll forward this email to LAT. MIDI with 2.6.26 MIDI has not been
mentioned there.
Since there's more of you LAD's compiling your own kernel that does not
work, what about posting .config, version/patchset and compiler info
before we all run into the same walls. - We're planning something like
this with http://wiki.linuxaudio.org/wiki/kernel/
Does anyone know of similar projects? How in your opinion can LAO best
supplement [rt] kernel bug tracking?
There's 2.6.26-rtX testing packages from various distributions eg:
http://linux.ilmainen.net/musix/temp/ or at
http://guests.goto10.org/~krgn/files/ more at LAT - none of which is
stable at the moment.
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkiu6E4ACgkQeVUk8U+VK0ItUwCguWgCtuPlnZoQQHVIDpVJRtvt
suYAoKkv8JvmehvEOtKq81ameZnxw7yn
=DXcK
-----END PGP SIGNATURE-----
Hi folks!
All the files are here:
http://www.musix.org.ar/ogg/mgg2008/lentitud/
On Musix 1.0 R4 (debian etch+backports)
Rosegarden 1.7.0 used to crash when recording MIDI from my sb live (it
begins to crash when recording the 4th DSSI track), so, I installed
1.6.1 (ftp://ftp.ourproject.org/pub/musix/deb-testing/) and went
almost Ok, sineshaper produced some strange "hang" to the rosegarden
sequencer (a note remains, and when I rewind or forward it makes all
the system slow... so I killed rosegardensequencer, and re-started
rosegarden)
apt-cache policy sineshaper
sineshaper:
Instalados: 0.4.2-1
But, it was a beautiful recording session: quantize, change note
velocities, move and fix some recordings was really easy, smooth and
comfortable, I love Rosegarden :D
I disabled the USB ports on my PC because they have the same IRQ as my
SB Live, then, I also used icewm because it's light.
rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
1340 FF 85 - 125 0.1 S< IRQ-10 EMU10K1
374 FF 75 - 115 0.0 S< IRQ-1 i8042
373 FF 74 - 114 0.0 S< IRQ-12 i8042
5 FF 50 - 90 0.0 S< softirq-high/0
6 FF 50 - 90 1.3 S< softirq-timer/0
7 FF 50 - 90 0.0 S< softirq-net-tx/
8 FF 50 - 90 0.0 S< softirq-net-rx/
9 FF 50 - 90 0.0 S< softirq-block/0
10 FF 50 - 90 0.0 S< softirq-tasklet
11 FF 50 - 90 0.0 S< softirq-sched/0
12 FF 50 - 90 0.0 S< softirq-hrtimer
13 FF 50 - 90 0.0 S< softirq-rcu/0
61 FF 50 - 90 0.0 S< IRQ-9 acpi
290 FF 50 - 90 0.0 S< IRQ-14 ide0
293 FF 50 - 90 0.0 S< IRQ-15 ide1
619 FF 50 - 90 0.0 S< IRQ-8
1215 FF 50 - 90 0.0 S< IRQ-6
1289 FF 50 - 90 0.0 S< IRQ-7 parport0
1774 FF 50 - 90 0.0 S< IRQ-11 eth0
3325 FF 50 - 90 0.0 S< IRQ-4 serial
uname -a
Linux musix1.0r4dvd 2.6.23-rt1 #1 SMP PREEMPT RT Sun Oct 14 15:17:12
EEST 2007 i686 GNU/Linux
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Duron(tm)
stepping : 1
cpu MHz : 1800.247
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts
bogomips : 3602.98
clflush size : 32
free
total used free shared buffers
cached
Mem: 350504 342596 7908 0 14960
146908
-/+ buffers/cache: 180728 169776
Swap: 2771132 20912 2750220
Spanish article: http://www.mastermagazine.info/articulo/13251.php
--
Marcos Guglielmetti - www.musix.org.ar Software Libre para Artistas
Y al final, como tan astutamente fue observado en la década de
1860: "Todo lo que era sólido se ha desvanecido en el aire, y el aire
y era algo que todos sabíamos que podíamos respirar libremente".
Y así nos encontramos confrontando un sistema de poder basado en las
ideas de las relaciones de propiedad que la tecnología de los
propietarios ya estaba haciendo obsoletas.
Eben Moglen, FSF.
http://www.mastermagazine.info/articulo/13220.php--------------------------
Banda: http://libraabedul.com/banda/
i too had my own 2.6.26-rt1 hard lock; for me 2.6.25.4-rt5 is most solid.
would recomend to others. rt-6, and .8-rt7 hard lock for me also. the radix
tree entry in general has to be off otherwise i get lockups btw, and group
scheduling off entirely.
hth
best,
g.
Hi there!,
I want to optimize JACK capabilities in running Linux PCs.
What JACK configuration parameters do I have to vary (and in what way) to
achieve that?
(by "that" I mean: minimum latency, zero noise and zero xruns).
I'm looking for something like a "standard procedure"...
...not just trying all the possible configurations of JACK and picking up
the most convenient.
(... maybe an "autoJACKtuning" program can be done for this purpose, but
there MUST be a procedure to follow)
Maybe you just can't tune the best of every system by following the same
pattern, but making the average best is what i'm looking for.
I'm working in a program that's a metronome that reacts to human
synchronization errors (to the very same metronome).
That errors are just some milliseconds, and a further advance in the program
would need reacting as quickly as that - Fast!.
In some ways, the program is similar to a tap-tempo thing, but it's meant
for synchronization experiments.
That experiments are aimed at researching how do people sync themselves to
outer stimuli, like... the beat of a song.
Results of that can end up in cool stuff - e.g., the possibility of making
the sync of drum-machines REALLY human-like.
Well...
This program should be as "portable" as it can be.... but I'm having trouble
with some audio cards.
I don't think powerful sound cards are needed for this task... the
bottleneck seems much more of a OS scheduling thing.
I turned to JACK because of the promised low latencies and throughput (and
an easy API)...
... but sometimes the audio crackles, has xruns, can't get it to work even
with high latency, etc... and I don't have a clue about what to vary to fix
that.
Besides that, I'm kind of a musician too and it seems everybody who uses
JACK wants low low low latency and good sound, so a "guide" to tune up that
would be a step forward to the self promotion of JACK-based software.
Sorry for my Neanderthal-ish English
and cheers from Argentina,
Trece.
> > I got rid of rtirq and das-watchdog entirely. after that, the machine
> didn't
> > lock up for at least as long as Robins session, ~45 mins, but the in the
> > middle of some session I would have liked to keep the recording of,
> dang..
>
> sorry, but without rtirq the whole thing is useless.
>
really? how so? I mean I can understand what it doesn, but I personally
havn't seen it doing anything significant for i/o performance. that said, I
don't really do latencies lower than 128 samples... let me know your
view/experiences/hints.
thanks
karsten