Re: [LAU] -ck patch

On 12/13/2010 01:13 PM, Paul Davis wrote:
> 2010/12/13 Raffaele Morelli <raffaele.morelli@email-addr-hidden>:
>> 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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon Dec 13 16:15:02 2010