Subject: Re: [linux-audio-user] Audio routing issues for linux..
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Mon Jun 10 2002 - 22:59:00 EEST
On Mon, 10 Jun 2002, Juan Linietsky wrote:
> Here's a problem I commonly find in existing audio apps or in
> programming audio apps: Audio routing.
Over a year ago (Sat May 05 2001) I wrote the following message:
... pretty close isn't it? The next step was http://eca.cx/laaga and then
[problems of JACK and aRts]
> 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.
I don't really see a problem here. There are already JACK clients that
allow you to modify the set of published ports during runtime. JACK apps
can either let the user specify what ports to publish or it can query the
running JACK system and create its ports based on this information. It's
just like communicating with any other rt-subsystems (direct soundcard
access, network, etc).
> 2-Jack is great, but if you want to run a certain synthethizer that
> doesnt use jack, together with one that does and you have a consumer
> soundcard that doesnt support multichannel output, you are dead.
You've been dead so far, are dead and will be until a real solution to
this problem arrives. JACK is one promising project (my personal
opinion of course), but it's still an open game... who knows, maybe
Steinberg will announce Rewire/Linux next week and we can pack our bags
and go home. ;)
> 3-You may also want to put just any program that uses native OSS/ALSA
> through this. Imagine running xmms and wanting to put the sound thru a
> better equalizer than the one included. Instead of botherering in
> writing a SPECIALIZED equalizer plugin for xmms, you just redirect the
> output to an equalizer program that takes many inputs/outputs.
Notice the date. In other words this is certainly possible with JACK and
has been for a while!
> 4-I know jack likes to give root privileges to apps that need low
> latency I imagine that for normal apps this isnt an issue, so this
> should be considered.
Yup, this is a problem, but it's a problem for all apps. And btw, JACK
nowadays has a "soft-mode" which allows you to run it without
root-privileges. You'll get the occasional xruns, but it'll run. The
choice is yours.
> 5-You know you cant force application owners to convert their stuff to
> jack/arts/etc. You'd also rather not waste your time converting their
> applications to that, and the application owners would rather not
> having to support multiple apis. So, this saves us time to all.
Maybe you are right, promoting JACK (or any other new framework) is a very
difficult task indeed. On the other hand I really think JACK is something
very exciting. I've already started to work on adding JACK support to a
few of my favorite linux audio apps so I can use them in combination with
ecasound. What can I say... it's like a whole new ball game! :) Like it or
not, JACK as it is now can do things that simple weren't possible before.
It's here, it's real and it works! :)
> Probably the easier and more natural approach to this is just
> integrating JACK to ALSA in some way.
This is not as easy as it sounds. I've thought about this a few times when
I was working on Ladplex (my own implementation of the LAAGA concept which
I later abandoned in favor of JACK). You could implement most of jackd's
functionality in the alsa-lib layer, but not without problems:
- you'd need a separate server (and with it all the installation/user-support
problems you mentioned as problems of JACK); otherwise you'd have no
sane way of resolving the user-privilege problem
- only with ALSA apps that behave like JACK-clients would
efficient low-latency operation be possible (in other words
the ALSA API, although certainly allows it, doesn't force app
writers to make their apps efficient for lowlatency operation)
- no transport control
- you'd need a separate API for making connections and querying
current network configuration
- it's a big task; even with a very limited interface, JACK has
required quite a lot of developer effort; ALSA PCM API is,
well, it's just larger
If we don't worry about low-latency too much, then the situation changes.
It shouldn't be too big of a task to write an ALSA PCM plugin that
interfaces with jackd using libjack. This would allow all ALSA and OSS
apps to interact with JACK. I'm certain someone will write this bridge
sooner or later. A simplified version would do:
- lock the ALSA hw parameter space to the values given by jackd
- treat JACK like a soundcard
- pcm plugin layer is used to convert between formats used
by JACK and ALSA (here JACK is the 'hw' device)
- when JACK delivers an interrupt, the bridge code
updates the "hwptr" and checks whether ALSA app should be
- sw-params like avail_min, and start/stop threshold can
be used to control to bridge operation
- ... you get the picture
There shouldn't be any great technical difficulties in implementing this.
But ALSA and OSS apps using this bridge won't be as efficient as native
JACK clients and don't have access to all JACK functions. And yup, for
many uses this isn't a problem. But as efficiency and low-latency is what
most current JACK developers are interested in, this type of bridge code
doesn't yet have top-priority.
PS You can also think of this bridge as JACK embedded in alsa-lib
if that sounds nicer to you. >;)
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Mon Jun 10 2002 - 22:46:47 EEST