Subject: [linux-audio-dev] Re: Video JACK?
From: Jelle (jelle_AT_defekt.nl)
Date: Tue Oct 30 2001 - 23:51:55 EET
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
> the execution of a number of clients by telling them "do whatever you
> have to do within <time period>", where the time period is currently
> denoted in audio frames, but should probably include a temporal
> interval as well or instead. thats where the "perfect sync" comes from
> - everyone's doing whatever their thing is at the same time for the
> same time.
>
> i don't see how you can fit a client into that scheme which
> needs/wants to be driven by another clock source. however, if you can,
> then great, since MIDI needs this kind of functionality as well. let
> us know what you have in mind.
>
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.
you have to analize the graph to figure out which components are
connected to what clock source. For example, a MIDI-in --> proc.
--> MIDI-out graph would connect to a interval thread to give
the smallest possible latency. MIDI-in --> audio-component -->
audio-output would connect to a audio interval. etc.
for 2,3,4 this works in-process but could work out-process as well,
since the clock source would be JACK.
all the context switches between 1 and 2 are not so cool, but I can't
think of another way.
to implement 1 into JACK you would have to create a function that
triggers the interrupt thread in JACK when needed.
this is more or less my idea on this, hope it is of any use.
feel free to ask, cause there's far more issues regarding this, but i've
left them out for now.
cheers
jelle.
-- jelle herold (defekt) http://defekt.nl/ seeing digital http://channelthree.net/
This archive was generated by hypermail 2b28 : Tue Oct 30 2001 - 22:57:50 EET