Subject: Re: [Alsa-devel] Re: [linux-audio-dev] Ways to make Linux THE ULTIMATE Multimedia Processing System
From: Paul Davis (pbd_AT_Op.Net)
Date: Sun Dec 16 2001 - 06:57:34 EET
>Nothing I said was new of course (as I tried to note several times), I
>was simply trying to add my own enthusiasm to this topic. Perhaps you
>didn't get that though, at least I gather from your response.
sorry about the tone of my response. days of grappling with the total
fsck-up that is autoconf/automake, trying to finish the implementation
of libgnomecanvasmm for gtkmm 2.0, worrying about how i was going to
deal with cross-fading in ardour, bratty kids treating me a taxi
driver and a lack of sleep has contributed to an-even-more-than-usual
unpleasant tone in my voice. i apologize. its not necessary, and not
helpful.
>When I think of where Jack comes into the picture. I realize that it is
>trying to accomplish a similar thing as LADSPA or aserver. That is,
>streaming audio data to other applications. Now I know you have stressed
>time and time again that you are going for sample sync, low latency,
>standard floating point streams, but the overall object is the same.
Not really. aserver, like esd and artsd before it, have been focused
on simply bringing data streams together before delivering to an audio
interface. at this time, there is nothing in ALSA to facilitate
inter-process audio exchange, though the framework to write such a
thing (in user-space) is certainly there and it would not suprise me
if Abramo, Jaroslav or someone else adds this soon.
However, as i hope my recent exchange with kai shows, when you start
adding to the requirements of what you consider an acceptable
solution, sometimes what you're actually doing is solving a different
problem. as Kai has noted, JACK is really about building a synchronous
execution engine. inter-app data exchange and sample sync operation
possible are really just consequences of this design.
if you start out saying that the goal is to share data, you will find
(as evidenced by the available solutions) several different ways to
get there. if you start out saying that the goal is to have a
synchronous execution engine, the pathways change in important ways,
and are a bit more constrained.
>If we create multiple standards for the same desired effect, we are
>going to be fragmenting application development.
You have specified what the desired effect is. If its sharing data,
there are at least 3 available solutions, and perhaps more if you
include JACK as well as the audio stuff in GRAME's MidiShare.
If you require synchronous execution, then JACK is the only functional
or semi-functional solution. ALSA doesn't do this, and neither does
anything else.
This is why I like to focus on ALSA as the equivalent of CoreAudio's
HAL. I love ALSA. I just don't think its the API that most programs
should be written around unless it changes in some important ways (or
rather, provides some simplifications), provides some new
functionality, and encourages a certain kind of program design more
actively. this doesn't seem like the role of ALSA to me, though i
could change my mind about that.
>hardware? An API that satisfies all our needs (or at least as close as
>possible).
but josh - what are those needs? 90% of the people who write "audio
code" for linux couldn't give a damn about synchronous execution or
low latency, if they even knew what those terms meant. Abramo has been
correct to take me to task for rather narrowly defining what the
acceptable solutions look like, and he's write in the sense that there
are many users and applications which really don't care about this
stuff, but still want audio interface sharing (for example), or
believe that they want inter-app data routing without sync execution.
i prefer to start from the most demanding set of requirements and work
backwards from there. until ALSA provides inter-app data sharing, and
until most/all ALSA native apps use a poll-based design, ALSA can't
meet those requirements. so, to meet those specific requirements, a
different API is needed, one that forces the correct design
methodology on programs and provides inter-app data sharing so that
this set of requirements can be met.
then, i'm happy to work backwards to how we can fit less demanding
requirements into the picture, and as far as i can see, aserver will
do that perfectly well if and when it can talk to JACK.
>How about integrating the ideals of JACK with LADSPA? They are both
>constructed around the idea of networks of audio processing nodes. Could
>LADSPA 2.0 be JACKed :)
JACK is, in some ways, my own take on a certain version of LADSPA
2.0. a lot of what's in LADSPA has been stripped out because a JACK
host doesn't want to know much about it clients and because ports are
dynamically allocated rather than being something to lookup in a
shared object. the work on in-process clients (the closest equivalent
to LADSPA) is not finished, but it works for the driver-as-client case
already.
more fundamentally however, i think this is missing the point of what
LADSPA was for. it was getting really silly seeing yet another delay
implementation being written. LADSPA provides a
lowest-common-denominator way to pack up common DSP algorithms and
reuse them in many different programs. it doesn't deal with
inter-process data sharing, and doesn't try to. things that implement
LADSPA are not programs as much as algorithms with a discovery
protocol wrapped around them. as such, i don't see JACK and LADSPA as
being any more similar than, say, JACK and ALSA.
>of moderation here. I don't want to see the audio world in Linux be
>fragmented like the Desktop world is already becoming. The underlying
>protocols should be standard, flexible and independent.
heh. the classic response to this is "pick any two".
i share your concerns, but i am not sure what can be done about
them. there is no dictator to impose CoreAudio on everyone. we can do
our best to provide solutions, advertise them, improve them, use them,
but beyond that, this is linux, and people are, sometimes
unfortunately, free to do whatever they want.
--p
--------------------------------------------------------------------
Linux is not the penguin. Linux is the smile on the penguin's face.
This archive was generated by hypermail 2b28 : Sun Dec 16 2001 - 06:54:20 EET