14 Dec
2010
14 Dec
'10
2:36 p.m.
Paul Davis wrote:
On Tue, Dec 14, 2010 at 3:59 AM, linuxdsp
<mike(a)linuxdsp.co.uk> wrote:
I understand the issues raised (I've been involved in this stuff long
enough to know exactly what a difficult and complex task it really is) -
my comments were intended more as a light-hearted, rant about the fact
that surely by now, audio on PCs should 'just work' :) - and I should
add that I've encountered much the same issues regardless of OS, and
this was not intended to be critical of any part of the linux audio
infrastructure.
In fact the main reason I prefer linux as a platform for audio is that
you CAN tweak things to make it work, as opposed to other systems which
hide these things away from the user. (sometimes though, I just wish
that wasn't necessary) and when it works, linux audio works very very
well, but what makes it frustrating is that these kind of configuration
issues have a habit of cropping up and making it very difficult to put
that case to the average 'non-technical' user.
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.