23 Jun
2009
23 Jun
'09
5:28 a.m.
Dennis Schulmeister schrieb:
Hi,
On Mon, 2009-06-22 at 15:08 -0700, Fernando Lopez-Lezcano wrote:
Just a small comment. Its not about computation time so much, its about
regular scheduling.
On Mon, 2009-06-22 at 18:00 -0400, drew Roberts
wrote:
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.
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).
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.