Hi Martin

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 realtime scheduling.
<going into way to much explanation here, but perhaps someone may find it interesting>
But the kernel can be better or worse at actually keeping this realtime promise.
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. If
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 :)