[LAD] FW: [piksel] The future of videojack ?

Stéphane Letz letz at grame.fr
Wed May 7 07:28:24 UTC 2008

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 ((-:


More information about the Linux-audio-dev mailing list