linuxaudio.org

On Mon, 2009-06-22 at 00:15 +0200, Lennart Poettering wrote:

quoted text
> On Sun, 21.06.09 11:09, Paul Davis (paul@linuxaudiosystems.com) wrote:

> > I cannot imagine wanting to use this mechanism. You also seem to

> > have assumed that everyone agrees that SCHED_RR is the correct

> > policy, rather than SCHED_FIFO.

>

> If people can make a good case for SCHED_FIFO, then fine, we can add

> that to rtkit.

>

> Personally, I believe that RR vs. FIFO is not so much a decision that the

> programmer should make. I think this is more a decision for the admin,

> because this influences fairness between consumers of RT.

It is, ultimately, a decision for the _user_ to make. RealtimeKit should

also take that into account. 
As a user doing critical audio, say, in a concert situation, I'd require

that my computer's realtime audio tasks can use 99.9% of the cpu for

short amounts of time. I don't care if the rest of the user processes

are momentarily slowed down (up to a point, of course). I would very

much care if my computer, due to a temporary overload, decides to a)

glitch the audio and b) demote the rt process to SCHED_OTHER

permanently. It looks like the RealtimeKit is designed to do exactly

that by default. 
If that is the case, how can I regain control of what I can do without

having to resort to extreme cases of root configuration file magic, etc,

etc (what RealtimeKit is supposed to avoid). 
-- Fernando
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev