linuxaudio.org

On Wed, 2011-06-01 at 08:06 -0400, Paul Davis wrote:

quoted text
> On Wed, Jun 1, 2011 at 7:49 AM, Nick Copeland  wrote:

> > I might get flamed for this however GUI should not really be run with rt

> > priority,

>

> anyone who would do such a thing is a fool, indeed.

>

> > that is an honour for the DSP engines. There are some reasonable arguments

> > however for leaning on the scheduler with renice for the user interfaces to

> > give

> > them a bit of a bias over other system operations.

>

> what are those arguments? keep in mind that the algorithms inherent in

> SCHED_OTHER are targetting console-driven applications that do varying

> balances of disk i/o, computation and user input/output. they really

> don't address the situation of an app that needs to redraw with a

> relatively fixed interval on screen, nor do they provide any actual

> scheduling guarantees, which means that any disk i/o issues cannot be

> solved with nice  - you still have to plan for and deal with the worst

> case scenario (which is why ardour's default disk i/o buffers are

> *FIVE SECONDS* long (we really have seen delays of this length when

> reading from disk!). nice becomes even less relevant  in an era of

> separate i/o scheduling algorithms that are not designed to pay much

> (sometimes no) attention to nice values.

This brings up I/O scheduling, which is nowadays just as configurable,

but little discussed 'round these parts... I would think delays that

crazy should definitely be avoidable, particularly in combination with

pre-allocating contiguous disk chunks (fallocate w/ ext4 extents)
Do we (Ardour) have users hitting the limit of their system's disk I/O

abilities?  I'd bet that tinkering with this stuff would yield a

considerable improvement...
-dr
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

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