Paul, As you obviously know more about Jack than I do, can you explain how an API like Jack could provide information to the APP so that Audio and Video can be kept in sync.
Cheers James > -----Original Message----- > From: Paul Davis [mailto:[EMAIL PROTECTED]] > Sent: 14 January 2002 15:30 > To: James Courtier-Dutton > Cc: [EMAIL PROTECTED] > Subject: Re: [Alsa-devel] Alsa and the future of sound on Linux > > > >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
