Subject: RE: [linux-audio-dev] Still I cannot understand why...
From: Ivica Bukvic (ico_AT_fuse.net)
Date: Fri Dec 14 2001 - 23:49:50 EET
> The fact is that a lot of the people on this list don't really care
> about the entertainers. They just want to build the stage or smoke
some
> herb and swim in the water. Are we going to get on their case about
it?
> No one can stop that but why bother.
I am sorry, but I think I lost ya somewhere in this lengthy analogy...
Who is getting on anyone's case? I am simply commenting on the stuff
that needs to be improved, while contributing to the community by
programming (soon to be released app) and in the process of doing so
realizing what is becoming a frustrating issue (at least for me both as
a programmer and composer). No one is trying to criticize people for
putting sw/hw contributions to linux before musical composition. It just
happens that in my case I would like to do more composition than I do
sw/hw tweaking (as would many other composers using linux out there, I
am sure).
Finally, to add to your partially comprehended analogy, if it were not
for the "entertainers" there would be no need to build a stage in the
first place, neither would there be an inspiration to even think of
building a stage, nor the need for stage-builders to exist... (besides,
I do not think of myself as an "entertainer," but rather as an artist.
On the other hand, I might have undermined the "art of programming" and
"tweaking" with my previous statements, and for that I do apologize).
In another words, no one is getting on your or anyone else's case on
this board. I am just trying to get to the bottom of the problem that
has been bothering linux audio developers and users alike, and is yet to
be resolved. Most people call it constructive criticism...
> Why not give us a detailed breakdown of how you think your idea can be
> achieved?
As I said before:
[trying to summarize based on everything I said and learned from this
thread so far]
My thought is to develop a sound daemon that would be compatible with
older apps using esd and artsd, based on alsa-server, with the
efficiency of jack, and ability to share audio resource(s) with the
priority settings (so that the desktop warning bleep would have less
audio priority than the real-time 8-channel recording/playback going on
at the same time), as well as patchbay-like ability to route signals,
making Alsa the backbone of the audio system on linux, while
phasing-out/replacing the inefficient OSS aspects. On top of that
documenting Alsa should be the highest priority at this point, thus
stimulating developers to use Alsa instead of OSS.
A joint effort would make this not only doable but relatively quickly
achievable. Imagine just how much time does each programmer waste on
implementing their own version of efficient sound signal pooling process
within their own application. Now multiply that by the number of linux
sound apps out there. If we used that same time invested by all
developers on implementing their own version of the solution to this
problem, and concentrated on developing one universal solution to this
issue... Well, you get the idea.
Now, I must admit that there are aspects of this daemon stuff that I am
not too familiar with and am not sure whether this kind of architecture
would be capable of producing sample-synced and at the same time
low-latency output (as Paul has pointed out), so I am not sure whether
this would in the end be an universal solution. But even if that
wouldn't be the case, it could still be used to improve audio resource
sharing issue, while making extreme low-latency stuff something that
would have to be dealt with on individual basis (maybe the daemon could
be circumvented through a reserved high-priority thread, while still
offering a user-friendly way of "feeding" the /dev/dsp with audio
buffers in a highly efficient manner).
Ico
This archive was generated by hypermail 2b28 : Fri Dec 14 2001 - 23:44:49 EET