>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
