Subject: Re: [linux-audio-dev] Audio routing issues for linux..
From: Paul Davis (pbd_AT_op.net)
Date: Mon Jun 10 2002 - 08:38:10 EEST
>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.
>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.
>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.
This is solved if you use capabilities. Since capabilities are known
to be The Future of POSIX (which includes linux), this is the correct
solution. If you have a kernel with capabilities enabled, JACK can be
used without any root permissions on any program except "jackstart"
which is used to start the server itself.
Otherwise, this is just a basic problem with any POSIX-like multiuser
OS. You can't grant the right to run SCHED_FIFO to anyone because it
implies the capability to DoS the machine. If Linux was a single-user
system, perhaps this would be OK (though perhaps not). But anyway,
Linux isn't, and so one way or another, there are hoops to jump
through here.
And also try to clarify things a little better: its not applications
that need low latency. All JACK clients get whatever latency the
server provides them. Its *users* who need low latency and its
therefore users who choose to run jackd with or without realtime
scheduling.
>Probably the easier and more natural approach to this is just
>integrating JACK to ALSA in some way.
Look, LAD has been over this dozens of times:
* ALSA already has the "share" PCM device type which allows
multiple access to the same underlying hardware. It hasn't
been tested very much, but it does basically work.
* such a design is like artsd and esd in that it cannot guarantee
synchronous execution of all participants in the "sharing".
This might be OK for some purposes, but its not OK for
serious audio work.
* aserver by itself doesn't permit inter-app routing, but alsa-lib
could support such a thing. the LAD archives are full of a raging
debate (mostly between Abramo and myself) about the appropriateness
of such a design strategy.
* the only known design that enforces synchronus execution is the one
used by JACK, PortAudio, CoreAudio, VST, LADSPA, ReWire, TDM and
many others.
So, yes, we can carry on promoting APIs that don't enforce synchronous
execution and end up with a complete mess, or we can promote APIs that
will allow this (even if a given implementation might not use that
feature).
As I've said before, Linux is not like MacOS, where Apple have been
able to say "CoreAudio is the way". All we can do is to advocate
certain design approaches. There are a bunch of people out there who
seem to think that using OSS and/or ALSA makes sense. We can either
persuade them that they are wrong, or make do with a non-synchronous
execution, with or without inter-app data sharing. But neither you nor
I nor anyone else can make that choice for other developers.
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!" :)
--p
This archive was generated by hypermail 2b28 : Mon Jun 10 2002 - 08:31:05 EEST