> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jelle > Sent: 30 October 2001 21:52 > To: [EMAIL PROTECTED] > Subject: [linux-audio-dev] Re: Video JACK? > > > On Tue, Oct 16, 2001 at 10:09:46AM -0400, Paul Davis wrote: > > hi there, i said i would get back to this after i messed up my exams and > that is now :) > > > >would you, at all, be interested in extending JACK to mediate video > > >connections between software (even with variable clock rates)? > > > > if you can see some way to do that, then sure. personally, i > > don't. the whole model upon which JACK is based is a single periodic > > "tick" source (not necessarily with a regular period, however) driving [...] > okey, there is about three distinct signals that you want to schedule > > - fixed interval (audio at 44100/blocksize intervals per second) > - variable interval (video, framerate as high as possible) > - interrupt driven (incoming midi events, external clock) > > I am working on a potential JACK client that incorporates all of > these signals. All components in the graph have a "process()" function. > > My idea was to seperate the different clocks and provide my own > scheduler. the schedular loads a scheme (more or less) such as: > > 1. If there are any interrupts process them > 2. process the audio at (interval) unless running 1 > 3. process video when audio is done > > it uses some kind of relay-system that passes a token around, so that > only one thread is run at the same time. The audio thread has higher > priority than the video thread and thus the video thread is stopped when > the audio thread gets intervalled. > > I've implemented something that does 2 and 3 and that works very well. > Audio is always in time and video goes as fast as possible, iaw is > processed in CPU's "spare-time". i've extended this to do background > loading in a thread 4 and that works just fine. [...]
I'd be interested to know if this fits with the LADMEA approach (see www.ladspa.org/ladmea). --Richard