On Sat, 29 Sep 2001, Richard W.E. Furse wrote: [lots of comments snipped]
> > What worries me about LAAGA/JACK is that a very specific approach is taken > to exchange implementation that isn't right for some tasks (e.g. bandwidth > management, networking, handling of varied data types) although it is very > good at some other things (e.g. low latency PCM audio). What I'd like us to > investigate is a way forward in which clients can still make use of > LAAGA/JACK when these features are the user's priority, but don't restrict > the exchange to this form. In particularly, IMHO remote inter-application > communication for audio software is HUGELY important for the future and I > think the Linux audio community really needs to address it sooner rather > than later. This API should be perfectly adequate for a "rewire"-style > exchange. It also should be fine for a world in which a studio is made up of > a network of rackmount Linux boxes, MIDI controllers, SP/DIF connections and > ADSL connections to other studios. > It is certainly true that there is only one type of "exchange" currently written for JACK, and that is for low-latency PCM. This does not mean that the API is not suitable for other types of connections, though. I think the beauty of the JACK API is that the clients have so few responsibilities, which actually makes it easier to provide different backends. I would certainly be interested in some specific cases that you think cannot be handled by the JACK api - as Paul said, now is a good time to talk about these issues. Karl > > --Richard > > --------------------- Karl W. MacMillan Computer Music Department Peabody Institute of the Johns Hopkins University [EMAIL PROTECTED] mambo.peabody.jhu.edu/~karlmac
