[LAT] [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)

[Fernando Lopez-Lezcano]

On Mon, 2009-02-02 at 20:24 +0100, Lars-Erik Helander wrote:
> Fernando your elaborate response is highly appreciated, thanks!!
> 
> >>   - Will "rtirq" make a difference on a non-RT-patched kernel system?
> >
> > No AFAIK. Non-rt patched kernels do not have irq processes running as
> > separate SCHED_FIFO threads (which is what is tuned by rtirq).
> >
> This was my thought to.
> 
> >>   - Do I need to assign rtprios explicitly to all my processes
> >> (qjackctl, qsynth, ...) or is that "automagic"?
> >
> > Automagic. Jackd gives the proper priority to the clients (to the thread
> > of the client that handles audio i/o)
> >
> I use "lmms" every now and then. I have never been able to get "lmms"
> to work well with jack so I use it with ALSA as the audio driver. This
> works fine though I can not use jack application simultaneously. So in
> this case do I have to explicitly give "lmms" SCHED_FIFO and rtprio?
> How (using chrt?) ?

If you want you could use chrt. I don't know if lmms is multithreaded,
if so you would/should change into SCHED_FIFO the audio thread. Even
then the application should be well designed, otherwise it could hang
the whole machine. 

> >> I have close to 30 years experience in developing realtime systems and
> >> has been using Linux for audio in various distribution the last two
> >> years. Further I have built RT-kernel for couple of distributions
> >> (this weekend I successfully built and ran a 2.6.28-rt kernel from the
> >> new git tree :) ).
> >
> > Ah, I have not tried this yet! How did that work out? Any errors or
> > problems on boot? How exactly did you go about building the whole thing?
> >
> About a week ago building from the git produced a kernel that did not
> boot properly, actually it did not even build properly and my own
> remedy for the build problem resulted in a kernel that was not able to
> boot up properly. However building from the git this weekend produced
> a well working kernel. Only problem found is the softirq.c bug that
> has been around for a while (it makes USB MIDI keyboards etc not to
> work - they are discovered but no MIDI events are received) so I had
> to apply a patch for that problem.
> Build procedure was very straightforward using the git url I cloned
> the git and got myself a complete (already "patched" kernel source
> tree) and it was just to do the normal "make oldconfig", "make
> menuconfig" ... procedures.

I see, I just tried with no luck. It may be a configuration option that
triggers compile errors (or something else I'm not doing right). 

-- Fernando


> >> However I have no experience in using newer non-RT
> >> kernels but I am very interested to find out how well you can have
> >> them work, especially since whenever you find a nice distro you can
> >> not use it because the hazzle of building an RT-kernel for that
> >> particular distro is so big :(.
> >
> > Planet CCRMA (http://ccrma.stanford.edu/planetccrma/software/) has rt
> > patched kernels of the 2.6.26.8* flavor for fc9 (in the "testing"
> > repository) and fc10, and should be easy to install (not an objective
> > assessment, I created and maintain Planet CCRMA :-).
> 
> I have also sucsessfully built and used 2.6.26.8-rt13 with the Slitaz
> (www.slitaz.org) distribution (the git kernel also works with that
> distribution).
> In order to use the kernel with my USB MIDI devices I had to apply the
> above mentioned softirq.c patch.