On Thu, 2002-03-21 at 15:49, Paul Davis wrote: > ALSA already has support for zero-copying I/O, via its mmap mode.
Thanks for your reply, Paul. I'm not as familiar with ALSA as I should be, but I did know about mmap mode and its performance implications. I hadn't assumed that the latency between application and hardware would be the bottleneck, but rather that the latency between applications would be. I guess I should have been more specific: I was thinking that the greatest benefits might be in zero-copying I/O for IPC, to support a chain of filters/effects a la those in commercial programs like "Reason" or similar. Of course, that's irrelevant if all such viable systems use explicit shared memory to pass data through different effects. (I personally think that message passing or pipes are easier abstractions than shared memory, but I realize that that's an unpopular view.) I guess that the kind of application I had in mind was something like GNU Octal, but development on that seems to have stagnated. > scheduling latency is really the only issue i've every had > with the kernel. I just read one of the KURT papers (http://www.ittc.ku.edu/kurt/papers/KURT-vienna-paper.ps). I agree; dynamically introducing a different scheduling policy when applications need it (or, as a first cut, ask for it) seems like the Right Thing to do. One interesting (but unfortunately likely irrelevant to audio) thing that some dynamic optimization research has been aiming for lately is a sort of bidding/guaranteeing mechanism. For example, an application will ask for disk throughput of speed X mbps or N functional units in the CPU, and the hardware/OS will be able to make guarantees about what it can provide, so that the application will be able to modify itself to work well under temporary resource constraints. This is mostly applicable to devices that are power-constrained, but I've seen other useful applications for it as well. I suppose there might be an application for allowing an application to specify a desired scheduler resolution (and receive feedback from the kernel on what resolution it could actually supply), but I can't think of one. > --p <once, [EMAIL PROTECTED]> :-) Actually, I believe I knew that; I've actually skimmed your Mach threads paper. Oddly (or not) enough, I found it when looking for info on using CPS in OS design. Ah, what you learn from arbitrary citeseer traversals. Thanks, wb -- Will Benton | "Die richtige Methode der Philosophie w�re eigentlich die: [EMAIL PROTECTED] | Nichts zu sagen, als was sich sagen l��t...." **GnuPG public key: http://www.cs.wisc.edu/~willb/pubkey
