Re: [Jack-Devel] Just a thought: Sometimes...

On Sat, May 25, 2013 11:08 pm, Florian Paul Schmidt wrote:
>
> Hi people!
>
> A saying in maths is "Often it's easier to solve the generalized problem
> than the particular problem instance one is pondering" [paraphrased].
> This post is just a incoherent(?) rambling on what could be the more
> general problem a tool like jack could solve and how the current use of
> jack is just one particular instance of that problem.
>
> Jack is an awesome tool. It allows flexibility in audio routing (and
> more recently midi routing) between vastly different applications,
> services, and tools. But like Paul, and others, have noted, jack
> development with respect to new features has kind of stagnated. I want
> to chime in with a maybe fresh approach to thinking about what jack does
> and how the development of other useful abstractions (like CV ports, but
> also stuff like semantically grouping ports, etc.) could be facilitated.
>
> Jack was initially developed exclusively for audio routing, albeit with
> some preparations for extending the buffer types. This has then done
> with jack midi. For other kind of data this model has become problematic
> though. There is one centralized code base which tries to be the
> solution for all things linux rt audo related. Often a more
> modular/extensible approach has proved to be more fruitful. A library
> which gives users and developers the opportunity to build their own
> abstractions/standards on top of the core set of features. This is also
> a little nod into the direction of LV2 which has its extension mechanism
> and in general to the UNIX philosophy of building small tools that work
> together in concert. The core tools should be flexible enough that new
> data types can be implemented independently of them. Maybe once they
> have proven to be useful they can be integrated into the core
> distribution or standardized in another way.
>
> So coming back to the original question what is the more general
> problem: Jack really is a particular solution to a more general problem
> than just routing audio and midi: How to define and run a data flow
> graph of nodes of applications/services/tools with real time constraints
> on the transport and the execution of the nodes and how to constrain the
> data going over the edges of this graph in such a way that different
> apps/modules/services understand each other.
>
> Maybe it makes sense to ponder if it is is possible to try and create a
> solution for the more general problem of just creating a generic
> transport and scheduling tool for a dataflow graph of nodes with
> realtime constraints. Maybe even relaxing the real time constraints and
> treating them as yet another specialization of the problem makes sense.
>

Over here we are working on JACK-3D for transporting 3d modelling data
between 3d engines like blender and cube2 (for instance).

There is also JACK-Video from Salsaman.


> Of course there is always the danger of taking too much of a mouthful
> for the scope of a project. Something completely general with no
> specialization gets nothing useful done at all. So the question really
> becomes: what level of generality and what kind of abstractions are
> useful now and for future purposes which we are not even aware of yet.
>
> Ideally such a tool would be flexible enough that the current jack API
> could be implemented as a special case thus providing backwards
> compatibility while at the same time being ready for the future.
>

I think JACK is already the defacto platform for sharing realtime data
across FLOSS multimedia applications. Nearly every audio app supports it
and many video apps too.


> Feel free to flame me :D
>

Your right on the money as far as I am concerned.




--
Patrick Shirkey
Boost Hardware Ltd

1369487693.14307_0.ltw:2,a <52640.188.26.171.156.1369487682.squirrel at boosthardware dot com>