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

> On Sat, May 3, 2008 03:27, salsaman@email-addr-hidden wrote:
> > Hi all,
> > after some long and protracted discussion with the jack developers on
> > their mailing list, I have come to the conclusion that they will
> probably
> > never accept the videojack patches into the main jack trunk. I also made
> > some suggestions to make jack startup easier for non-technical users,
> and
> > these were rejected. The attitude seems to be that the goal of jack is
> > simply to make a high quality server for audio, and if this means adding
> > complexity to the startup, requiring kernel patches, etc. then so be it.
> >
> > Some of the jack developers suggested to me that I look into using
> > pulseaudio (http://www.pulseaudio.org/) since it seems more suited to my
> > needs. I haven't had a chance to look into it deeply yet, but it looks
> > like an interesting project.
> >
> > As a result of all this, here is what I suggest:
> >
> > - we maintain our own fork of jack based on the current videojack code
> and
> > clients and backport any fixes from the main jack trunk as well as we
> can.
> > For this it would be nice to have a CVS/SVN set up.
> >
> > - use the vjack-devel mailing list from BEK to discuss development of
> this
> > branch
> >
> > - look into pulseaudio, and see if it might be possible to make a
> > "pulsevideo" - if it seems possible and wise, approach the pulseaudio
> > developers and see if they are more open to accepting non-audio patches.
> >
> > - discuss the pros and cons of writing something like videojack from
> > scratch - basically, what is needed - a server that provides timing and
> > calls callbacks and uses shared memory to pass framebuffers; client code
> > which connects to the server and sets up the callbacks; control
> interfaces
> > to list, connect, and disconnect the clients
> > - or maybe it's better to make a stripped down version of vjack that
> only
> > handles video ?
> > - think about whether we want to be able to synch with audio from jack
> > and/or pulseaudio.
> >
> > Please discuss...
> >
> >
> > Salsaman.
> > http://lives.sf.net
> >
> >
> >
> > _______________________________________________
> > piksel mailing list
> > piksel@email-addr-hidden
> > https://www.bek.no/mailman/listinfo/piksel
> > http://www.piksel.no
> >
>
>
>
> Well, since nobody else seems to have an opinion on this, I guess I will
> go ahead with what I suggested.
>
> Here is what I plan to do:
>
> 1) register a project on sourceforge (vjack.sf.net ?)
> 2) check the current videojack code in to subversion; set up basic web
> page for vjack (this can later be pointed to jackvideo.org)
>
> 3) check the changelog for jack and backport any important fixes
> 4) trim down the codebase - remove all drivers except the "dummy" driver
> 5) change all occurances of "jack" to "vjack", eg in function names and
> enums; create libvjack
> 6) update all clients "jack" -> "vjack"
> 7) make the changes necessary for vjack - make rate a float; change
> default rc file to ~/.vjackdrc and allow an enviroment parameter to
> override the default location; change default server name from "default"
> to "video0"; allow vjack_connect, vjack_disconnect and vjack_lsp to
> specify a server name
> 8) create basic documentation and HOWTOs
>
> Since this is quite a lot to do, are there any volunteers to help with
> this ?
>
>
>
> Salsaman.
> http://lives.sf.net
>
>
>
> --
> "We are called to be architects of the future, not its victims."
> - R. Buckminster Fuller
>
> _______________________________________________
> piksel mailing list
> piksel@email-addr-hidden
> https://www.bek.no/mailman/listinfo/piksel
> http://www.piksel.no

Although I obviously do not know the whole story, this to me is highly
disturbing. Having video sync (like MIDI sync that is apparently being
worked on) within Jack would allow us to do professional sample-accurate
multimedia production. The alternative suggested above simply reinforces the
problem JACK in and of itself faces in respect to myriad of other (mostly
subpar) solutions. Given that we have a lot of contributors in our midst who
apparently are unable to find common language (so they go on to reinvent the
wheel with their own often incomplete implementation), it would be nice to
see LAD community (especially considering as small as it is) not propagate
this unfortunate predicament.

Once again, please note that the aforesaid is my gut-reaction as I obviously
am not familiar with the innards of this matter.

Best wishes,

ico

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue May 6 16:15:02 2008