Re: Video JACK?, was Re: [linux-audio-dev] What about OpenML? Some questions

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

Subject: Re: Video JACK?, was Re: [linux-audio-dev] What about OpenML? Some questions
From: D. Stimits (stimits_AT_idcomm.com)
Date: Wed Oct 17 2001 - 02:09:00 EEST


Jelle wrote:
>
> On Mon, Oct 15, 2001 at 06:57:27PM -0400, Paul Davis wrote:
>
> > >If and how could it be fit into LADSPA or JACK? Or should OpenML be the
> > >graph-host and host LADSPA plugins (so you may get hardware benefits)?
> >
> > LADSPA and JACK are completely orthogonal to one another. LADSPA can
> > exist without JACK, and vice versa. What they share in common is no
> > more (or less) than they share with every other callback based media API.
>
> I am aware of that.
>
> But I was looking at it this way. OpenGL provides many h/w functions,
> duplicated in s/w, that give you great speed advantages if you use them.

Perhaps you should look at OpenAL for a realistic audio analogue to
OpenGL graphics. Anything you find in it is open and not proprietary,
and is not vaporware.

D. Stimits, stimits_AT_idcomm.com

>
> I was suggesting that maybe OpenML could provide some processing
> advantages if it was integrated in a LADSPA host, by for example,
> letting all the mixing and equalizing be done by hardware... (ignoring
> OpenML's lack of callback model and latency issues, zero-copy gone etc)
>
> but thanks.
>
> > >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)
>
> cheers
> --
> jelle herold (defekt) http://defekt.nl/
> seeing digital http://channelthree.net/


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

This archive was generated by hypermail 2b28 : Wed Oct 17 2001 - 02:06:30 EEST