Hi, On Mon, 2009-06-22 at 15:08 -0700, Fernando Lopez-Lezcano wrote: > On Mon, 2009-06-22 at 18:00 -0400, drew Roberts wrote: > > I don't think I saw any assertion in the thread as to the benefits of > > enabling > > RT by default for all desktop users? (I may have missed it or forgotten it > > though) What is gained by this? What are normal desktop users doing than > > needs RT? (I am asking out of a large pool of ignorance here but I have a > > feeling from the thread that people may not be seeing the benefit of > > this...???) > > Basically playing sound. So that playback does not skip and can have > reasonable latencies. If the process that is playing sound gets > preempted out because of the workload of the machine and can't feed the > sound card soon enough you get a click. Humans are very sensitive to > that (more than to, say, a missed frame in video playback).
Then the assumption is that an audio-playing process belongs to the top-priority processes which deserve the most computation time (on a typical desktop system). I wouldn't agree to that assumption. Sure I do have a media player running in the background and I don't want the playback to click or skip. The same goes for video watching and so on. But I might accept drop outs if the machine is under heavy load (like when compiling a large program, rendering a video, ...) and don't want the media player to consume all the computation power. But then latency is no issue either as a media player most often plays static files which can be read in advance to keep the buffers full. The same goes for web streams which need to be buffered anyway in order to compensate jitter and limited bandwidth. Typically between 1/3 and 1/5 second is responsive enough for most desktop applications and still makes for plenty audio buffers even under non-rt situations. So after reading all those messages I'm somewhat left up wondering if the addressed problem (real-time audio for desktop applications) really is an existing problem. The same goes for the theoretical threat of a rt-fork bomb. Just because in theory someone could write such a program and make it run on a someone else's machine doesn't seem like enough reasoning for implementing a protection mechanism on a large user base. In theory there are much more real threats for the average user which nobody cared to address. And it has been shown that in theory the suggested protection mechanism can be circumvented, too. BTW: I read the README file and don't see why it should be required reading for this thread. Lennart explained it much better through his mails than the README file (which contains two typos :-). Yours sincerely, Dennis Schulmeister PS: Sorry Fernando for first sending this directly to you. -- Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany Tel: +49 721/5978883 - Mob: +49 152/01994400 - eMail: den...@windows3.de Now moved to the corridor: Hermes! (http://ncc-1701a.homelinux.net) Besides that: http://www.denchris.de - http://www.motagator.net/bands/65 <GnuPG KeyIDs: B8382C97, 01AD62DE> _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev