OK, here I go ranting about the same thing again... Can't help it :-), tired of fighting the issue. :-(
Here's a simple proposal that I have been thinking of (even though my computing skills are not so good when it comes to system stuff), and you please tell me whether this is a good idea: 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 care at all what is behind the /dev/dsp resource, addresses the /dev/dsp resource, it gets rerouted to the appropriate buffers provided by the sound daemon. This way, infinite number of apps could read and write into the same buffer, (writing being a bit trickier to do obviously) and being down-mixed in software. If the app works with larger buffers, it just simply reads off of the buffer longer and by the same token writes into the audio buffer as needed (daemon would adjust incoming buffer to app's needs by reading its OSS or ALSA request for the audio buffer). 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 it can be that is by making itself transparent. Therefore there would be no need for JACK-ifying or ARTSD-ing of an app. It would simply work (a concept that we definitely need more of in the Linux world). 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 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. Any comments and thoughts would be appreciated! Sincerely, Ico
