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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Florian Paul Schmidt-2

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.

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.

Feel free to flame me :D

Flo
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Just a thought: Sometimes...

Patrick Shirkey

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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org