[LAU] -ck patch

Robin Gareus robin at gareus.org
Mon Dec 13 14:25:44 UTC 2010


On 12/13/2010 02:28 PM, Raffaele Morelli wrote:
> 2010/12/13 Robin Gareus <robin at gareus.org>
> 
>> On 12/13/2010 01:13 PM, Paul Davis wrote:
>>> 2010/12/13 Raffaele Morelli <raffaele.morelli at gmail.com>:
>>>> Hi you all,
>>>>
>>>> what do you think about that? Have you got some personal experience?
>>>> http://ck-hack.blogspot.com/2010/10/bfs-in-real-time.html
>>
>> yes. In short: Desktop performance: amazing, Desktop-audio-performance:
>> good, pro-audio performance: deficient.
>>
>>> This quote:
>>>
>>> "If you were doing semi-professional audio recording you might, and
>>> then you'd need to understand the inner workings of the software and
>>> the -rt patchset to make the most of it. Just patching it in and
>>> expecting it to work for you will not really give you any advantage."
>>>
>>> is not really true. It is true that there are quite a few complexities
>>> to using the RT patchset's full capabilities. Most people probably do
>>> not use them. But this doesn't mean that a general claim that the
>>> patchset offers them no benefits is wrong.
>>
> 
> I really hoped that :)
> I am now sure that RT patchset is something for kernel folks to deal with,
> but neverthless that it's something good to apply for me.
> 
> 
> 
>> quite, but it is true in the sense that 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.

2c,
robin


More information about the Linux-audio-user mailing list