>I have looked at the Jack web page (http://jackit.sourceforge.net/) > >It would help more if jack.h had more documentation for all api function, >and not just a few of them.
well, we're not quite finished with the API yet. Once its really set in stone (for v1.0), something that i imagine will happen once i finish getting ardour to work with it (which is shaking out a lot of big issues that need addressing for supporting a large, complex application like ardour), full documentation will be added to the header file. its important, however, that the API stay simple for simple things. the sample clients in the current tarball are meant to illustrate just how simple things can be. >I have a particular application in mind, and was wondering how Jack would >handle it. >1) Audio and Video Sync > >Here there is no requirement for low latency or synchronous execution. >The requirement is just that the app is told exactly how long it will be >between the next samples written to the driver, and there is no such information in an SE-API system. all you get told is how much time we expect you to generate and/or process data for in this instance of your callback. SE-API's do not promise continuous execution, nor linear passage of time, nor monotonic direction of time. this is true of ASIO, VST, CoreAudio, PortAudio, TDM and every other SE-API that I know of. so, when your JACK client's process() callback is executed, it will be passed an audio frame count (we are debating whether this is the best or only unit of time to use). the process() callback is expected to do the right thing for the amount of time represented by those frames. if its an audio playback client, it will ensure that that many frames are present at all of its output ports. if its an audio capture client, it will read that many frames from each of its input ports and do something (probably lock-free and very fast) with them. if it a video client with audio playback, it will probably act like the audio playback client and additionally schedule another thread to handle video and/or update the video thread's idea of "current time". and so on and so forth. if the client cares about absolute time against a reference time base, it must pay attention to information about where we are in time that can be otained through the API. a client that is not the timebase master must be ready to accept that time may move at different rates, may move backwards or stop altogether. --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
