[LAD] [Jack-Devel] Re : The future of videojack ?

Juuso Alasuutari juuso.alasuutari at gmail.com
Wed May 7 19:37:24 UTC 2008

Stéphane Letz wrote:
> Video in jack1 won't happen because of several reasons that can be 
> explained again: we want to fix and release jack1 soon and video in jack 
> is a too big change to be integrated in the current state of the 
> proposed patch.
> The future of jack is now jack2, based on the jackdmp new implementation 
> (http://www.grame.fr/~letz/jackdmp.html). A lot of work has already been 
> done in this code base that is now API equivalent to jack2. New features 
> are already worked on like the DBUS based control (developed in the 
> "control" branch) and NetJack rework (developed in the "network" branch).
> I think a combined "video + audio in a unique server" approach is 
> perfectly possible: this would require having 2 separated graph for 
> audio and video running at their own rate. Video and audio would be done 
> in different callbacks and thus handled in different threads (probably 
> running at 2 different priorities so that audio can "interrupt" video). 
> Obviously doing that the right way would require a bit of work, but is 
> probably much easier to design and implement in jackd2 codebase.
> Thus I think a better overall approach to avoid "video jack fork" is to 
> work in this direction, possibly by implementing video jack with the 
> "separated server" idea first (since is is easier to implement). This 
> could be started right away in a jack2 branch.

I'll throw in my 2 Euro cents.

If the VideoJACK crowd feels that JACK2 development is taking too slow 
and decide to continue with their fork, may I suggest that we all still 
discuss and draft a proper video API together? If a fork happens out of 
practical reasons, it would be best to make sure that switching video 
software to use JACK2 later on will be as painless as possible.

Technical issues aside, I wish that those affiliated with VideoJACK do 
not feel that their needs are neglected by the JACK developers. I hope 
that the recent discussion has proved that people in this camp are 
willing to improve JACK in this respect. Perhaps we could move on and 
try to find more common ground?


More information about the Linux-audio-dev mailing list