>After having read many of the threads going on here, it seems that a lot >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.
we're not trying to code around it. thats a misunderstanding. the 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?" the reason Linux is attractive is that its a general purpose OS. its 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). >Linux and GNU always pride themselves on being modifiable by the people >who use them. So is it possible that, if we're having such a burden >coming up with decent algorithms we're not. > for working through these problems in >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? You assume that none of the people working on Linux audio are kernel hackers and that none of us have a history working on OS design ? :)) --p
