>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