Linux-audio-tuning August 2008

linux-audio-tuning@lists.linuxaudio.org

12 participants
16 discussions

by Rui Nuno Capela

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

16 years, 4 months

Re: [LAT] [LAD] Patching linux 2.6.26.3

by Robin Gareus

-----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-----

16 years, 4 months

2.6 stable

by Robin Gareus

-----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-----

16 years, 4 months

Re: [LAT] [LAD] Patching linux 2.6.26.3

by Robin Gareus

-----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-----

16 years, 4 months

testing rosegarden 1.7.0 and 1.6.1

by Marcos Guglielmetti

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/

16 years, 4 months

linux-image-2.6.26.1-rt-libre1 and linux-image-2.6.26.2-rt1-libre1

by Marcos Guglielmetti

Hi, Hola, new kernels for testing purposes: (nuevos kernels para testeo) http://linux.ilmainen.net/musix/temp/ http://linux.ilmainen.net/musix/temp/linux-image-2.6.26.2-rt1-libre1_2.6.26… http://linux.ilmainen.net/musix/temp/realtime/ http://linux.ilmainen.net/musix/temp/realtime/linux-image-2.6.26.1-rt-libre… (see the config* and readme files for more details) Cheers! -- Marcos Guglielmetti - www.musix.org.ar Software Libre para Artistas | URGENTISIMOOOOOOOOOOOO !!! POR FAVOR, HAZ CIRCULAR ESTE AVISO A | TUS AMISTADES, FAMILIA, CONTACTOS !!! En los próximos días, debes | estar atent@: No abras ningún mensaje con un archivo anexo | llamado: Invitación de hi 5, independientemente de quien te lo | envíe. Es un virus que abre una antorcha olímpica que quema todo | el disco duro C de la computadora. Esto no ocurre en las computadoras con sistemas operativos libres GNU/Linux, dado que son invulnerables a los virus. Windows sí es vulnerable. Información: http://www.gnewsense.org/Main:es/GNewSense Podés descargar GNU/Linux desde acá: http://cdimage.gnewsense.org/gnewsense-livecd-deltah-2.0.iso Suerte! -------------------------------- Socio de SOLAR: www.solar.org.ar

16 years, 4 months

2.6.26-rt1 et al

by Geoff Beasley

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.

16 years, 4 months

Re: [LAT] A guide to optimize JACK?

by Ben Tartsa

A bit dated, but may be of help: http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf

16 years, 4 months

A guide to optimize JACK?

by trece ocho

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.

16 years, 4 months

[Fwd: [pure:dyne] a working rt-kernel -- please test]

by krgn

> > 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

16 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Linux-audio-tuning August 2008