On Thu, Nov 22, 2001 at 12:37:36PM -0500, Paul Davis wrote: > 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.
Why not put it now, and mark it alpha quality? :-) > 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. This is obvious yes. > 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. Hmm, actually my application core is pretty much like JACK, now that I think of it. Every part that wants to read/write samples subscribes itself to a stream with a callback function. Once the audio driver (alsa) unblocks every subscribing clients' callback function is called with a buffer pointer and length. the callback function is then free to do whatever with the buffer. I'll do some shortcircuit hacking tonight I guess :) I'm still interested in a piece of sample code that outputs audible noise with the current jackd.... Thanks, Andy _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
