>There should be just a simple sound daemon running 24/7, constantly >reading from the /dev/dsp inputs and writing into the outputs with a >small circular buffer that keeps on recycling itself (i.e. 64 bytes to >allow for low-latency work if needed). Then, when an app that does not
sigh. i thought we/i explained this before. there are two performance characteristics of a sound daemon that are of interest here. 1) latency 2) sample synchronicity if you don't care about (1), then the basic design of esd will do *exactly* what you want. its a bit broken if you try to head for particularly low latency, but that just needs hacking to fix it (though quite a lot of hacking). of course, you need the LD_PRELOAD hack to make esd work, and this reflects the most basic and fundamental breakage in the OSS API: applications open a device driver and write to it using system calls, thus offering no way to interpose between the app and the device without linker hacks like LD_PRELOAD. i don't like, you don't like it, but its what OSS has forced on the world. in addition, alsa-lib contains the "mix" "plugin" which as has been pointed out very often is intended to do exactly what you describe as well but has not been tested by anyone except its author, abramo bagnara, who seems not to have the time right now to work on it. if you care about particularly low latencies, then you probably also care about sample synchronicity, even if you don't realize it yet. in which case, the design you are imagining doesn't work. you're thinking of what we generally call a "push model", where apps "push" data toward the playback device. i think that most people on this list concur that to ensure sample synchronicity requires a "pull" model on the part of the server, hence ... JACK. >Now, someone please tell me why is this not doable? Sound daemon must >be, at least in my mind, compatible with all software, and the only way "compatible with all software" ... including those that choose to use mmap mode, thereby writing directly into a memory buffer they believe represents the audio interface's hardware buffer (even if under alsa-lib, it might not be)? >I am sure that with the above description I have covered in a nutshell >both JACK and ARTSD to a certain extent, but the fact remains that both >solutions require application to be aware of them if any serious work is not if you use portaudio (well, soon, anyway). i'm a little unhappy about recommending a portaudio solution because i'd prefer to see more native JACK apps. but the truth is that the portaudio crew have done a fabulous job wrapping up both callback-based and push-model API's into a single unifying callback-based API. if you use portaudio, your software works (or will work soon) with ASIO, MME, CoreAudio, OSS, ALSA and JACK. >to be done. And as such, there is only a VERY limited pool of >applications that can be used in combination with either of these. i don't understand why you keep asking about this when esd exists and when abramo has already written the mix plugin for alsa-lib? if you don't like the qualities of esd, why not take that up on the development list for esd? if you want to try out the mix plugin, why not write to abramo and gently nag him to do something with it. --p