[LAU] jackd in realtime as user: a no-go in spite of modifying limits.conf

[Paul Davis]

On Tue, Dec 14, 2010 at 3:59 AM, linuxdsp <mike at linuxdsp.co.uk> wrote:

> I was going to start this email with "I don't understand why..." but I DO
> understand why (and that's what makes it more depressing) that there still
> needs to be so much tweaking required to get a modern PC to do audio (and by
> 'so much' I mean 'any').

this is wrong. or misleading.

there's very little tweaking needed that has anything related to what
you describe in the rest of your email. at present, almost all of the
issues come from one place and one place only:

   a general purpose OS considers the hardware as a set of shared
resources and thus provides limits on access to them

ALL of the tweaking required in Linux has to do with removing,
reducing or getting around these limits to access. if you build your
own kernel the RT patches and with a 2 line patch that allows RT
scheduling for anything and memlock for anything, then you're
basically good to go.

the old systems you mention basically didn't "schedule" in the way
that any unix-class OS does - stuff runs based on strict priorities
and doesn't get swapped off the CPU arbitrarily. that's why they were
absolutely useless as real world multitasking systems, but did very
nicely as 1-task boxes.

there is one other class of issues, and these come from hardware
components not related to the CPU but to the system bus. when other
peripherals illegally or even just inadvisably hog the bus for too
long, everyone suffers. sometimes this is caused by the peripheral
hardware itself, sometimes by the device driver (authors). this was
true in ye olden days too, but it was more catastrophic and made
things just not work at all. now, they work but just not very well.

finally, note that a general purpose OS does a LOT more than those old
machines in terms of policy - managing pluggable devices is a big one
that comes to mind, but there is also user management too, network
traffic handling and more - and the implementation of these policies
does get a bit in the way of a low latency scheduling code path
sometimes. that's why the linux RT patch is such a big deal, because
it basically gets these things out of the way of the scheduler.