Subject: [linux-audio-dev] Re: Lots about latency and disk i/o and JACK...
On Wed, 3 Oct 2001, Paul Davis <pbd_AT_Op.Net> wrote:
> we're not trying to code around it. thats a misunderstanding. the
Ahhh, that was my misunderstanding then. Before I joined the list, I went
> actually, even before that is the issue of "what do we want?",
Those are good questions. If they're not decided from the start, we're
> You assume that none of the people working on Linux audio are kernel
Oh no, I figured none of you would have the time for more projects..!<g>
> this is not strictly true. the IDE drivers (and devices) are the worst
These were the types of things I was reading that were making me think the
This archive was generated by hypermail 2b28
: Thu Oct 04 2001 - 01:35:28 EEST
From: Brent A. Busby (brent_AT_telepath.catmind.org)
Date: Thu Oct 04 2001 - 01:36:58 EEST
> mechanisms are already there (though there are a few kernel patches
> that provide better ones; for example, the "doors" IPC mechanism is
> the lowest cost one around - it comes from Sun and is a GPL'ed patch
> for the kernel). the issue is how to marshall these mechanisms so that
> they can be used in a relatively easy way to do what we want.
browsing through some of the old archives and came across some threads,
which I admit were from ages ago, that talked about one of the principal
problems in trying to write recording software for Linux being the way the
kernel seems to intend on caching writes nomatter what. I may have
misunderstood, and also that problem may no longer exist anymore.
> and after it also "and what does the API look like?"
likely to end up with a codebase that looks like ruins built upon ruins.
> hackers and that none of us have a history working on OS design ? :))
> offenders, but they are far the only place in the mainstream kernel
> where the kernel could block a runnable task for a (very) long time.
>
> for example, even in 2.4.0, with the low latency patch, it was
> possible to cause scheduling delays of 30-50-1000! msecs by hitting
> the VM and disk subsystems (e.g. a 4-process C++ compile while running
> Ardour).
kernel itself could be part of our problems. If it's possible to deal
with it from userland, that's okay, but in Linux, even the kernel is no
sacred object you can't touch if it really needs to be changed.
Again, all this is blathering from someone (me) who's just now in
the process of learning Perl...<g>