[linux-audio-dev] Quick and efficient sound daemon idea -- why not do it this way?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] Quick and efficient sound daemon idea -- why not do it this way?
From: Ivica Bukvic (ico_AT_fuse.net)
Date: Wed Oct 16 2002 - 07:58:53 EEST


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Oct 16 2002 - 09:25:56 EEST