RE: [linux-audio-dev] Re: Video JACK?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: RE: [linux-audio-dev] Re: Video JACK?
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Fri Nov 02 2001 - 09:56:50 EET


> -----Original Message-----
> From: owner-linux-audio-dev_AT_music.columbia.edu
> [mailto:owner-linux-audio-dev_AT_music.columbia.edu]On Behalf Of Jelle
> Sent: 30 October 2001 21:52
> To: linux-audio-dev_AT_music.columbia.edu
> 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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Nov 02 2001 - 09:57:19 EET