On 12/13/2010 02:28 PM, Raffaele Morelli wrote: > 2010/12/13 Robin Gareus <robin@xxxxxxxxxx> > >> 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. >> > > 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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
