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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jun 23 12:15:02 2009
This archive was generated by hypermail 2.1.8 : Tue Jun 23 2009 - 12:15:02 EEST