[LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

[Dennis Schulmeister]

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: dennis at 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>