Dennis Schulmeister schrieb: > 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. > Just a small comment. Its not about computation time so much, its about regular scheduling. > 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. > Even if its for memory reasons, media players don't read even static files totally in advance. media is rendered in chunks. of course its a good idea to do some extra buffering in non-interactive playback case where latency does not matter so much.
I'd say most users would prefer if the media playback can ensure smooth playback. Stefan > 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. > > _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev