[linux-audio-dev] Linux Audio Hardware Selection

[Paul Davis]

>At Fri, 24 Jan 2003 08:09:44 -0500,
>Paul Davis wrote:
>> 
>> the other alternative that many of us here like rather a lot is JACK
>> (http://jackit.sf.net/), which provides a different model: data
>> sharing between applications, shared access to hardware,
>> sample-synchronous execution of all applications, and no hardware
>> parameters to be configured. it sits on top of ALSA (and potentially
>> other similar hardware abstractions).
>
>what i've thought of is to make libjack runnable as standalone without
>jack server.  i know it sounds useless for serious purpose.

not at all. it would allow programs to be run with no context switch
overhead if they are started alone without jackd, which would be
rather nice. we need to get in-process clients done first, though.

imagine: your program can run in either mode - networked to other
applications and sharing the audio interface, or running with high
efficiency all by itself. all this with no code changes to your
application! 

>but, at least, people can write the application using a simple API,
>and have possiblity to debug in different environment.

i've had the same idea. my approach would basically be to have libjack
try to contact the server. if it fails, then it just starts up a
thread to run the audio loop, and then instantiate the client as an
in-process client.

>for example, in the standalone mode, libjack will initialize the
>necessary hardware setup silenty according to the config file, so that
>in the application you don't need to set up the nasty things.

>(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?)

because that means we have a config file, which means we need a config
file parser, which means we need to replicate a bunch of code or link
against another library. if jackd was a commonly executed command for
users, i could justify that. as it is, i can't.

--p