> >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.
Some comments. API which pretends to be "one and only" for linux must work not only with "high-end" but also "low-end" application ( like "embedded" mp3 player made of old Pentium-90 box ) i.e. server must be aware of general system perfomance, and don't eat all CPU time by pumping PCM data in 100 sample chunks. I'd prefer have possibility to negotiate with the server beseides the sample rate the output delay window (say 20..25 ms or even more ). In this case server must deside on his own how oft and how big chunks are demanded, depending on CPU perfomance / load, length of connection chain (I.e. mp3 or whatever player with compressor attached)... and use the biggest possible buffer lenght to assure that latency is in this window. More, there some time-domain effects like compressor, or some FFT based like vocoder, which naturally have some delay, and I think, there should be a possibility to tell to the server how big is it. I'm thinking about sample-accurate mixing down with real-time effects. Track with such effects applied must be "played ahead". I didn't found such functions in JACK API. Roman _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
