Le 6 mai 08 à 23:31, Juuso Alasuutari a écrit :
> Paul Davis wrote:
>> There has never been any disagreement with the idea that videojack
>> is a
>> cool idea. What there has been is a widespread feeling in the JACK
>> developer community that the video JACK stuff has been done
>> suboptimally, in ways that don't reflect a good understanding of
>> JACK's
>> design, and without bothering to actually ask us "how should we do
>> this?" I'd love to see videojack be a part of mainline JACK, but
>> its not
>> going to happen with the current set of patches that have been
>> proposed.
>> To be honest, I was suprised that everyone else at the JACK
>> "summit" at
>> LAC2008 seemed to agree with me about that.
>
> VideoJACK does sound nice, and it would be a shame to witness forkage
> when things could be settled in a more productive manner. I'm in no
> way
> qualified to draft any API plans for JACK, which arguably is the
> perfect
> excuse for doing just that. ;)
>
> I've understood that the current VideoJACK approach is to run two JACK
> servers, one for video and one for audio. If it already works with two
> completely different servers, wouldn't it also work if audio and video
> ports just had different callbacks inside the same server?
This could be the idea but "different callbacks" would require
handling two separated graph, that is video and audio do not run at
the same rate *and* audio callback would need to be able to interrupt
video computation (probably means different priorities for audio and
video threads...).
>
>
> The audio callback API wouldn't need to be changed in any way. Video
> streaming capabilities would require adding a smallish additional API.
> Here's a crude suggestion:
>
Post jack 2.0 I think ((-:
Stephane
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed May 7 12:15:02 2008
This archive was generated by hypermail 2.1.8 : Wed May 07 2008 - 12:15:02 EEST