ondemand is no good because when it switches the processor actually stops for a very short time. but this short drops are enough to cause the terrible xruns on jack. stick to performance or conservative :-)

On 01/08/2011 03:55 PM, Robin Gareus wrote: I kinda hoped we didn't have to do this... The exact same computer running ubuntu 10.04 with rt kernel (from ubuntu repos) works fine with ondemand, although I can push it harder when set to performance. This kernel gives xruns and audible glitches with ondemand even at light loads. And the reason why I wrote "not really a problem" (besides the hope of not having to go here) is that I am perfectly aware of the potential problems with ondemand govenor. -- Atte http://atte.dk http://modlys.dk

On 01/08/2011 03:55 PM, Robin Gareus wrote: I don't use frequency scaling when using JACK, especially after having read this: http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-March/022590.html But I guess now that empirical data is available which shows that the opposite might be true regarding CPU scaling this doesn't stand ground firmly anymore? A few mails later Paul does point out thought that he wouldn't use CPU scaling on a realtime low latency machine "at least not today". Best, Jeremy

On 01/09/2011 04:40 PM, Robin Gareus wrote: Not sure, I've never seriously worked with Jack2 and I've never tried tschack. What I do know is that a lot of users have benefited in the past from disabling CPU scaling regarding xruns (http://linuxmusicians.com/viewtopic.php?f=27&t=844)844). Personally I've never thoroughly tested CPU scaling and low-latency performance simply because I always disable CPU scaling right away. Yes I realize that too, that's why I added the quote "at least not today". Guess the day after today might have arrived? Best, Jeremy

On 01/12/2011 03:09 AM, torbenh wrote: Hello Torben, Time to adjust the LinuxMusicians Wiki then :) And I'll try if scaling works ok on my notebook. Won't try it on my netbook, that one has got a buggy timer chip so scaling eventually locks up my whole system (that's what you get when buying cheap stuff). Best, Jeremy

On 01/12/2011 11:17 AM, allcoms wrote: Liquorix doesn't offer a realtime kernel and the Pengutronix one is specifically made for industrial purposes iirc. So your best bet is probably the 64Studio realtime multimedia kernel. But then I'm not a regular Squeeze user. http://wiki.debian.org/DebianMultimedia#Realtimekernel Best, Jeremy

On 01/08/2011 03:55 PM, Robin Gareus wrote: anecdotal evidence: on my system(s), using ondemand is absolutely deadly when using the ffado backend. with the alsa backend, the system is mostly ok when running ondemand, but then again i run fairly high latencies because jconvolver gets really expensive when you shrink the period size...

On 01/07/2011 08:14 PM, Josh Lawrence wrote: The liquorix kernel is not a RT kernel. And I tried the 64 Studio kernel, had to change the apt line though: deb http://apt.64studio.com/backports squeeze-backports main contrib non-free Tried to reboot, kernel panic. Could be because this was on Sid. The Pengutronix kernel works fine. But it doesn't have the nouveau driver so I can't use it really. Yeah, I could compile it myself but that actually boils down to rolling my own kernel. Leave that for another time. Best, Jeremy

On 01/07/2011 09:15 PM, Robin Gareus wrote: Is there also a 64studio RT kernel for Lucid? Regards, \r

On 01/07/2011 09:34 PM, Robin Gareus wrote: Ok, I'm interested in your view about that kernel. Is it good practice to install a debian kernel for Lucid? \r

On 01/07/2011 10:03 PM, Robin Gareus wrote: Or it should be a special repo for the kernel... Then updates should be possible. \r

On 01/08/2011 11:00 AM, rosea.grammostola wrote: That's a question for Daniel or Free (CCed). I'm not too much involved with infrastructure on 64studio.com. best, robin -- Robin Gareus web: http://gareus.org/ mail: robin(a)gareus.org lab: http://citu.fr/ chat: xmpp:rgareus@ik.nu Public Key at http://pgp.mit.edu/ http://gareus.org/public.asc Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42

On 01/07/2011 09:15 PM, Robin Gareus wrote: Thanks Robin for the pointer. No initrd indeed, but do_initrd is set to yes. I'll try creating the initrd manually like you suggest. Best, Jeremy

On 01/07/2011 08:14 PM, Josh Lawrence wrote: I've just read config-2.6.36-2.dmz.8-liquorix-amd64 and no it's not a -rt kernel. It's got PREEMPT but not PREEMPT_RT. Yet there's not that many differences between the config-2.6.33.7.2-rt30-multimedia-amd64 (64studio) and liquorix config otherwise. The most prominent ones are that liqorix uses "BFQ" instead of "CFQ" disk scheduling algorithm and "performance" rather than "ondemand" CPU governor by default. On two test systems here CFQ with combined with NCQ yielded lower latency through slightly less max throughput. But it's a decision to revisited for 64studio once 2.6.37-rt is out. There's a few minor things that could be optimized with liquorix. amongst others e.g. disable CC_STACKPROTECTOR and RELOCATABLE for the last pinch of perfomance, but maybe better safe than sorry. BTW. There's no RT patch for 2.6.36. Recent vanilla kernels are fine these days unless you really need reliable low latency (let's say < 10ms ~ 256*2 fpp @ 48k). -- Robin Gareus web: http://gareus.org/ mail: robin(a)gareus.org lab: http://citu.fr/ chat: xmpp:rgareus@ik.nu Public Key at http://pgp.mit.edu/ http://gareus.org/public.asc Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42

I can speak for my personal experience, Arch is the*most stable system I have ever used.

Maybe I was just lucky. But with MacOS, Ubuntu and Fedora I got a few crashes, never got one with Arch. Maybe just a random thing of life. One reason would be that since you just install what you want, there are less variables playing the game. Maybe the packagers don't put new stuff in her/his packages... Or maybe updated packages tend to have less bugs. I really don't know why.

for my user case arch is fair enough, just perfect. fedora is also pretty good.

Nothing. That was just a brief digression from another comment.