Well I thought that 2.6.28 has realtime capabilities built in and it is not
> necessary to apply any patches. At least I can see realtime threads with ps
> and neither MusE nor jackd complain about lack of realtime capabilities.
This is a bit of a misunderstanding. Infact all POSIX compliant operating
systems support the scheduling type SCHED_FIFO, which in general is called
<going into way to much explanation here, but perhaps someone may find it
But the kernel can be better or worse at actually keeping this realtime
Several of the changes that have emerged in the RT patches have gone into
the standard kernel, hence improving it's realtime capability, if you want
to go the extra mile you may need the patches.
Infact, if your requirements are really-really high, linux won't do at all,
atleast not any version we are talking about.
This area of realtime that audio application reside in is generally called
soft-realtime. Could be described as 'noone dies if we miss a beat'. Which
may be the issue for critical systems, where hard-realtime may be required.
I guess what I'm trying to say (if you read this far) is that it boils down
to what you require. Myself I often run with a standard kernel, it gives me
good performance at 256-frames buffers, x-runs happen but not frequently.
And the system is very usable for other applications.
> My question concerned renicing PROCESSES in the light of realtime THREADS.
> I understand you correctly there is no point in doing this.
Right, it should not matter.
The question is rather if you have an actual problem or are just trying to
tune the last hertz out of your system?
The first one is easier to fix if you give us a rundown of the problem.
The second, ... well, there are always more tweaks to do :)
- cut down on running processes
- stop cron and similar stuff
- run a lightweight window manager
- use ramdisks
the list goes on :)