>> it is much easier to screw up a
>> kernel by blindly applying patches and generating a .config if you don't
>> know what you're doing (and sometimes even if you know what you're
>> doing). Also, one needs additional tools (like rtirq) to make good use
>> of RT-linux, while -bfs runs OOTB.
>> However these days most distributions do that setup for the users.
>>
>
> well, I always followed
> http://www.alsa-project.org/main/index.php/Low_latency_howto and never
> screwed up a kernel

Lucky you :) The information on the alsa-wiki is very good, but not
every user is diligently following instructions as you do.
It is also much easier to make a custom kernel that runs on one (your)
system only, than tackling the task of compiling one that can be
distributed.

>> I don't care so much about speed. The important issue in pro-audio is
>> reliability. It's not the smallest possible latency that counts, but the
>> max. latency of the system.
>>
>
> I really did not understand this statement and anyway I would not agree...
> why anybody should be safe knowing that his box max latency is 20ms instead
> of 50ms or 70ms?

The max. system-latency determines the audio-latency at which you will
never have any x-runs. (The minimal and avg. latency determines the
speed and reactivity of your Desktop.)

Without the RT-linux patch you may be good at 99.9% of the time, but
since there is no guarantee for system-latency: there may be drop-outs.

And Murphy says that this 0.1% chance will always become real when
you're on stage in the middle of a performance. The resulting click will
not only kill the PA but half the audience will sue you for becoming
deaf ;-)

An other use-case is a studio: It's not about low-latency there but
about no x-runs at all, they are just unprofessional. YMMV.