Subject: Re: [linux-audio-dev] Audio routing issues for linux..
From: Juan Linietsky (coding_AT_reduz.com.ar)
Date: Mon Jun 10 2002 - 10:18:06 EEST
On Mon, 10 Jun 2002 01:38:10 -0400
Paul Davis <pbd_AT_op.net> wrote:
> >Here's a problem I commonly find in existing audio apps or in
> >programming audio apps: Audio routing.
> >
> >The way things work now, it's hard for apps to implement a standard
> >way of:
>
> First, you can't do any better on MacOS or Windows, because ReWire
> or DirectConnect are the only (low latency) options and many
> programs don't support them. This is not a defense of the status
> quo, just an observation about how cutting edge this idea is, and to
> point out how much progress we are making on it.
Yes, that does suck on such OSs too :\
>
> >1-The application has to be able to "proovide" inputs and outputs,
> >which may be used or not. By default an app may connect directly to
> >the output or just not conect at all, expecting YOU to define the
> >audio routes. Most of the times, unless using a direct output or
> >known audio modifier objects, an app will not want to connect
> >somewhere from whithin it. You will do that from an abstracted
> >interface.
>
> Is there some problem here? The app should be able to save its
> state. If you invoke it again and the destinations/sources exist, it
> can restore its own state. if they don't, then you're asking it to
> do the impossible.
Yeah, but what I mean is 2 things, first that you should be able to
change transparently where the app is sending the data, without the
app noticing, and second that such configuration shouldnt be stored by
the app but from an abstracted app/interface that handles connections.
>
> We discussed this issue of audio routing for at least 2 years before
> JACK was written. No ideas other than the one represented by JACK
> emerged that I recall emerged till Abramo suggested extending
> alsa-lib. Very few people liked that idea, so now we have JACK as a
> viable option (well, the folks on jackit-dev think so, anyway), and
> alsa-lib remains without any options in this area. As they say "show
> me the code!" :)
>
Ahh, i think i didnt make myself clear enough, so i'll try to go into
more specific detail.
What I propose is:
-Audio routing/data sharing for ALL programs. For most it should be
audio routing via api calls.
-Low latency/syncronous execution only for the ones that _need_ that.
-Of course taking the audio from routes at different latency will
become lag.
-Transparency! What i've meant is someting like
program-> alsalib -> jack -> alsalib
for normal apps and:
program <-> jack -> alsalib
for low latency apps.
Does alsa need to be modified for such thing?
cant jack work as an intermediate driver for this?
I would basicaly like to be able to take the sound output of any
program and do whathever I want with it, such as connecting it as
sound input of another program, stabilishing a network of those.
The idea is to do this from an external program to the ones in use.
It's just like what the sequencer API does with MIDI, but the idea is
using audio, This would go well even from within alsa because the same
tols cold be used to connect stuff.
If you have ever used PD/J-max you might be used to this concept,
this proposal is simpler but also gives you a great amount of
versatility to your programs/environment. The advantages I see are:
1-Saves a _huge_ amount of time to programmers since the only thing
they have to do is register audio in/out slots, and then route the
external sources. How many times do we see programs use the same code
over, over and over again? (freeverb/chorus/flange/ladspa
chains/equalizers/normalizers/mixers/vu bars/etc). Well, this would
put an end to that, and audio programming becomes a lot easier.
2-Saves enormous time to the user. Why capturing/dumping/editing if
your CPU can do everyting at once? just chain your favorite programs!
It actually even gives you the ability to build up your own chains of
modifiers for program to program.
3-Encourages program interoperability, ala good old unix way. It's
easy, most programmers, and specially the new ones, dont care about
side libs such as JACK/Arts. They want to go straight to the official
api first. Many dont even care/bother/know how to write multipe output
drivers support so they just go to the official api. Many dont even
bother to find out if someting besides that exists. Or worse, many
will just not even bother to write a program because of how much it
takes to do certain things that, even when may be proovided by other
programs/modules, there's not an easy/standard way to use them.
4-Works for any application! put some groove to quake III,
filter out the noise of those old mpgs, raise the treble in those
cheapo speakers and add some reverb in the way.
5-Humillate the poor windows/mac users that cant do that on their OSs
;)
I understand that the "Show me the code" is worth more than a
proposal. I'm trying to give my view on the subject as an application
programmer. Having written sequencers, trackers and softsynth apps,
i'm giving you a perspective on how I think things would have been
much easier when programminf. Also how i'd like them to
intercommunicate to other programs for certain tasks.
A nice example is that a lot of people has mailed me saying "Could you
add a plugin api for CheeseTracker so I can use more effects than
chorus and reverb and chain them?". Others have asked me "Can you get
CheeseTracker to open multiple devices for each track so I can mix the
output in my roland mixing workstation?" Sure, I could go and write
that, even ladspa suppport, but I think it's far from the optimium
solution. I already have some plans for messing with the ALSA
internals, but I dont have much time, so i'd rather ask first to the
developers here, familiarized with the API about how real/crazy is my
proposal ;)
Regards
Juan Linietsky
This archive was generated by hypermail 2b28 : Mon Jun 10 2002 - 10:16:23 EEST