Subject: Re: [linux-audio-dev] Lots about latency and disk i/o and JACK...
>After having read many of the threads going on here, it seems that a lot
we're not trying to code around it. thats a misunderstanding. the
the reason Linux is attractive is that its a general purpose OS. its
>Linux and GNU always pride themselves on being modifiable by the people
we're not.
> for working through these problems in
You assume that none of the people working on Linux audio are kernel
--p
This archive was generated by hypermail 2b28
: Wed Oct 03 2001 - 03:18:28 EEST
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Oct 03 2001 - 03:21:31 EEST
>of the problems we're facing with i/o latency and cached writes and the
>like deal with the way the kernel handles the filesystem, and trying to
>code around that might not be the best way in a free OS such as ours.
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. actually, even before that is the issue of "what do we want?",
and after it also "and what does the API look like?"
possible to design an OS purely for streaming media (BeOS heads off in
this general direction, for example). if that was strictly necessary,
we should do it. but its not - we can use the existing kernel
mechanisms to do what we want (given the low latency patches and/or
the preemptible kernel patch).
>who use them. So is it possible that, if we're having such a burden
>coming up with decent algorithms
>userland, maybe someone like Alan Cox or Linus Torvalds or their legion of
>developers might be able to do something to the kernel itself that would
>make things generally all-around easier for the whole audio developer
>world?
hackers and that none of us have a history working on OS design ? :))