13 Dec
2010
13 Dec
'10
1:58 p.m.
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.
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.
Its really completely wrong
to claim that someone actually *doing* audio recording would need to
understand this sort of stuff - if you write software for that
purpose, then its more correct, but even then part of the point of
JACK is to hide that sort of thing for the majority of applications.
This quote:
"Human perceptible latencies are in the millisecond range, where
anything within about the 5ms range will not be noticeable. The -rt
patchset is designed to decrease latencies in the microsecond range"
is misleading, because it ignores the cumulative effects of scheduling
delays. You really do want stuff to just be as fast as possible.
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.
My own take on this is that Con Kolivas has some
interesting insights
and does some cool stuff with his scheduling patches, but he seems to
always be at odds with the other kernel scheduler folk. He also has
never quite seemed to grasp what realtime audio actually requires, and
in his defense tends to say that he's more interested in the
"desktop".
Anecdotally, a couple of people on IRC have noted that their desktop
behaviour with BFS is very nice. I haven't seen any evidence that its
better for RT scheduling than the current mainstream kernel, let alone
the RT patch.
I can second this: http://permalink.gmane.org/gmane.linux.rt.user/6512
FWIW: the "200 lines kernel patch" (also discussed on this list a few
weeks back), -bfs, etc are great to improve speed on the Desktop but
they do not yield _reliable_ low latency.
2c,
robin