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

Paul Davis wrote:
> On Tue, Dec 14, 2010 at 3:59 AM, linuxdsp <mike@email-addr-hidden> 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.
>

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.

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Dec 14 16:15:05 2010