> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jelle > Sent: 16 October 2001 12:19 > To: [EMAIL PROTECTED] [...] > > >And while I'm at it, can JACK transport other than audio signals, and > > >at another clock rate (say video)? > > > > In theory yes. The current reference implementation isn't complete, > > and so in practice, no. This will change soon. Note, however, that > > there is only one reference clock signal in a JACK system. If other > > clock rates are not integer multiples of the reference clock, then its > > difficult to make things work correctly. This is almost certainly true > > for audio/video integration. > > to be honest, I'd rather have a mixed callback and streamed system. It's > likely that video doesn't run at a fixed rate, but rather (eg.) as fast > as possible. (I'm writing software which integrates audio and video, and > the video can be switched between fixed_rate and variable_rate.) > > Streaming is probably beyond the scope of JACK, but it doesn't > seem usefull > to create another system for just transferring variable rate video (or > whatever). > > would you, at all, be interested in extending JACK to mediate video > connections between software (even with variable clock rates)? > > same question for LADSPA (i'm working on a extended "video"-version)
Of course, you could always take a look at alternative models such as LADMEA (idea-stage prototype at http://www.ladspa.org/ladmea/). --Richard
