On Tue, 2007-10-16 at 12:34 +1000, porl sheean wrote: > i think a few people have missed what i mean. after re-reading my post > i can see it wasn't all that clear. i am still using ubuntustudio, but > i downloaded the 64studio *kernel* (not the whole distribution, which > i tried but it wasn't quite what i wanted) to replace ubuntu's. Arghh, sorry about that, I thought you were running Ubuntu's kernel. So, everybody else, ignore my comments! :-) (maybe that was explained somewhere else in the thread and I missed that, sorry again). > after doing that, everything runs perfectly. i assumed that the ubuntu > kernel didn't have the rt patches set right, but after downloading a > vanilla kernel and patching it myself i noticed that my custom kernel > had the same problems as ubuntu's. whilst i am happy to use the > 64studio kernel, i am very curious as to what they have done to it to > make it work where both the ubuntu-rt and my own custom kernel both > have the same symptoms (*very* unstable audio at lower than 40ms > latency, and even then ardour often refuses to start plaback - jack > drops it off as soon as i press play sometimes on larger projects). That is strange (and interesting). > i did a diff of the config files from all kernels and couldn't find > any notable difference that would explain it (to my limited knowledge > anyway), Would you mind sending me (or posting) the configuration options for both kernels? (or rather, three, the one for Ubuntu Studio, 64studio and your hand rolled kernel?) > so i assume it is a patch that 64studio has applied in addition to the > standard rt patch that is making the difference. are there any other > audio performance enhancing patches for the kernel? Not that I know of, the only one I'm applying that is related to low lantency is Ingo's. And I imagine that 64studio uses something like the rtirq script to tune irq priorities, and that it would treat both kernels the same. Puzzling. -- Fernando > On 16/10/2007, Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx> > wrote: > On Sun, 2007-10-14 at 12:48 +1000, porl sheean wrote: > > i have actually had no end of trouble with ubuntustudio's > (and now > > ubuntu's) rt kernel. on an amd 6000+ system with 1gig ram > and a > > rme9652 soundcard i can't get reliable performance under 40 > or so ms. > > i even tried a vanilla kernel with the rt patches and had > the same > > trouble. the 64studio kernel worked fine, however. i'm > currently > > running at 5ms with it and have had no problems. this is > even with > > compiz fusion running and spinning the cube whilst playing > back audio > > from an 18 channel ardour project. what patches would cause > such a > > difference in performance? it isn't any options selected in > 'make > > menuconfig' - i loaded the 64studio's ones in and used them. > still no > > luck. i can only assume they have added more patches to do > with > > realtime performance than just the -rt patchset. > > >From what I gather ubuntustudio does not have an rt patched > kernel (ie: > patched with Ingo Molnar's realtime preemption patch). See > observations > below: > > > On 05/10/2007, thomas fisher <studio1@xxxxxxxxxxxxx> wrote: > > I can supply no quantifications for the 32 bit > 2.6.20-16-realtime > > kernel in ubuntustudio other than no xruns have been > observed. > > So, Ubuntu Studio has a kernel named realtime and they have > observed no > xruns (which is not your case, and not the case of other > posters). > Obviously it depends on how they test (hardware used, size of > buffers, > load on the machine under test, etc, etc) and there's no info > on that > post about that. > > > With the low latency kernel, xruns were observed. > > This implies they don't have the low latency patches applied > and that, > in their experience, the low latency patch was worse than the > mainline > kernel. > > If you have access to that kernel and you can check its build > configuration you could grep for "PREEMPT" there and post the > results. > That will definitely tell us which options were used for > building it (I > suspect you will find just "PREEMPT_VOLUNTARY" there). > > In my experience, a mainline kernel will lead to xruns at low > latencies > (there's always an exception, of course). > > > Jack is the only app that has a -20 priority assigned. > > This implies they are not using SCHED_FIFO for running Jack. > Apparently > they are boosting the normal scheduler ring priority of Jack > to -20. I > have not experimented with this so I can't comment, except to > say that > everyone else (that I know of) is using SCHED_FIFO for running > Jack - > SCHED_FIFO is a higher priority scheduling method that can't > be > preempted by regular linux tasks, and while it is more risky > as a badly > designed application can hang the machine, the tradeoff is of > course > much better realtime performance. > > > The general workstation has been running without fault. The > general > > Debian / Ubuntu philosophy tends towards system stability. > > The realtime preemption patch is certainly less stable than > the mainline > kernel. But if you hardware runs it fine then it is more > effective than > mainline for achieving low latencies. > > -- Fernando > > > > Tom > > On Wednesday 03 October 2007 14:54:32 Fernando > Lopez-Lezcano > > wrote: > > > On Wed, 2007-10-03 at 18:39 +0200, Frank Barknecht > wrote: > > > > Hallo, > > > > > > > > Matthias Schönborn hat gesagt: // Matthias > Schönborn > > wrote: > > > > > I've just read that there's a difference > between a > > realtime-kernel and > > > > > the low-latency-kernel provided by > ubuntustudio. The > > text in the german > > > > > wiki on ubuntuusers.de said, that a > realtime-kernel is > > slightly better > > > > > than the lowlatencykernel > > ( http://wiki.ubuntuusers.de/Echtzeitkernel) - > > > > > then why isn't it used in ubuntustudio? Or do > I just mix > > something up? > > > > > > > > I think, this wiki and maybe Ubuntustudio as > well are > > using a very > > > > confusing terminology. > > > > > > > > Generally we have two kinds of kernels: The > "vanilla" > > kernel as > > > > downloadable on kernel.org and the same kernel, > but > > patched with Ingo > > > > Molnars RT-patches. The vanilla kernel, if > configured > > properly with > > > > CONFIG_PREEMPT etc., already gives very good > performance > > in the low > > > > latency department, enough for many users, even > audio > > users. I run one > > > > of these. > > > > > > > > If you want more, then you can install a > RT-patched > > kernel, as is > > > > provided in the linux-rt or linux-realtime > packages. I > > would call the > > > > Ingo-Molnar-patched kernels Realtime-Kernels or > > Low-Latency-Kernels. > > > > > > To further clarify (or confuse?) the issue, how > "low > > latency" the kernel > > > is also depends on how you configure the kernel > build > > options before or > > > after patching the kernel with Ingo's patch. For > Ingo's > > patch > > > CONFIG_PREEMPT_RT is the best option in terms of > latency but > > there are > > > others (CONFIG_PREEMPT_DESKTOP) that have a more > > conservative approach > > > but have (relatively speaking) higher latencies. > So from > > worst to best > > > it would be something like: > > > > > > vanilla linuz + CONFIG_PREEMPT_NONE > > > vanilla + CONFIG_PREEMPT_VOLUNTARY (used by the > stock > > Fedora kernel) > > > vanilla + Ingo + CONFIG_PREEMPT_DESKTOP > > > vanilla + Ingo + CONFIG_PREEMPT_RT (the one I > use for > > Planet CCRMA) > > > > > > (there's more granularity and options in the > CONFIG_PREEMPT* > > world but > > > those are the ones that have the biggest impact as > far as I > > can > > > remember) > > > > > > -- Fernando > > > > > > > > > _______________________________________________ > > > Linux-audio-user mailing list > > > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > > > > > > http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user > > > > > > _______________________________________________ > > Linux-audio-user mailing list > > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > > > http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user > > > > _______________________________________________ > > Linux-audio-user mailing list > > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > > > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user > > > > _______________________________________________ > Linux-audio-user mailing list > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
