On 12/13/2010 02:28 PM, Raffaele Morelli wrote:
2010/12/13 Robin Gareus <robin(a)gareus.org>
On 12/13/2010 01:13 PM, Paul Davis wrote:
2010/12/13 Raffaele Morelli
<raffaele.morelli(a)gmail.com>om>:
> 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