On 12/13/2010 01:13 PM, Paul Davis wrote: > 2010/12/13 Raffaele Morelli <raffaele.morelli@xxxxxxxxx>: >> 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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
