>> i spent some time last week porting a nice little app called RythmnLab >> to use JACK. it used the same kind of design that so many linux audio > >Where can we get RythmnLab?
the original is linked from dave phillips' pages. my port (which i will rename, since i rewrote most of it to use gtkmm) is not packaged yet. i have one remaining bug to fix (not related to the JACK stuff) and then i'll put it on the JACK site for perusal. >> apps do - blocking reads and/or writes on the audio device. this >> approach just can't be used for low latency sample sync'ed >> performance. its precisely this goal that is so important to the >> Windows/MacOS proprietary s/w developers these days, and it should be >> for us as well, IMHO. > >Well, I would love to see the conversion you did since my JACK plugin is >suffering from the same thing: the rest of the applications expects >a blocking function call to control timing/streaming. i was going to send you the 2 central loops to compare them, but they wouldn't make much sense on their own. the key concept is that the process() call has to know where in the stream it is, and then generate the relevant data for just the right set of data. RythmnLab isn't the best example, since its rather complex (its generating poly-rythmic and/or poly-metric patterns from N different audio samples, so keeping track of where in time we are is rather tricky :) if the "rest of the application" truly expects timing/streaming from blocking read/write, then the application won't work with either JACK, PortAudio, CoreAudio and nor could it form the basis of a plugin for any plugin system I know. its precisely *this* difference that is so critical - the programming model created by blocking read/write calls just doesn't work for sample synchronous collaborative systems. actually, thats not strictly true. it can work, but it won't run in sample sync nor with particularly low latency. you simply have a process() callback that delivers N frames, but they are actually being generated in another thread which blocks when the shared buffer is full. audio will still stream in and out of the app, but not locked to all the other apps, nor with the same latency (because of the extra buffering). --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
