Re: [Jack-Devel] The Situation(s) With JACK

> I don't think we're there yet, i.e. neither netjack1 nor netjack2 is sufficient for all the use cases. They both look to me like prove-of-concepts that demonstrate certain things, but lack through engineering in other respects. E.g. how to accommodate future extensions (header-length fields, other codecs [than celt,float], ...).

Yep.

> 
> And while it is a nice thought of having only jack with exactly one perfectly tailored network protocol, reality is not so perfect. We should not forget that there are other network protocols out there (AVB, Dante, etc.) that some might want to see interoperating with jack at some point in the future.

Yes sure, important point also.


> And there are people out there that would be willing to connect via netjack, but without using jack at one end --

Already possible in NetJack2 (that is in SVN tree and in future 1.9.8 version): the "network stack" in available as a pure C API defined here: http://trac.jackaudio.org/browser/jack2/trunk/jackmp/common/jack/net.h and compiled in a separated library called "libjacknet".

Basically it allows audio components to be "netjack slaves" (and even possibly "netjack masters"). This is a prof of concept right now that we use here to test "remote audio processing" ideas, using a combination of Faust (http://faust.grame.fr/) and libjacknet. It works quite well...

> and need good documentation of the wire format.  From this perspective, and thinking of possible dependencies like DNS-SD, I'm even not too sure, if network protocols (esp. the "network manager" part should be "designed into the jack core".
> 

Let me explain how NetJack2 is currently structured:

1)  On master side, a component called "netmanager" developed as an in-server JACK client,  that listen to remote client connections request and create a JACK in-server "proxy client" on the master machine for each connected remote machine. Each slave machine starts with the "net" backend.

2) An "adapter" concept : basically the idea is to "adapt" the network stream on the slave audio system. Since JACK is running on 4 OS, we have developed 4 specific "audioadapters" one on each OS using : ALSA (Linux), PortAudio (Windows), CoreAudio (OSX), OSS/Boomer (Solaris). Those adapters are still to be improved, in particular they add a quite huge latency, and the adaptation strategy between the networks stream frequency and the slave audio card frequency is still not really satisfactory. Adapters are also developed as "in-server" JACK clients.

3) The libjacknet library concept : as explained, the idea is to export the "network stack" for non non JACK slaves.

4) Recent improvement like :

	- non connected JACK port optimization. Only data for really connected ports (on each side) are really transmitted. This save bandwidth in a lot of use cases.

	- integer and CELT sample encoding

My general felling is that this design already has some qualities that make more suitable for future evolutions in the right direction. The "in-server" JACK clients model allows fine control with any strong control API based approach (like the DBus+ladish one), since in-server client can be configurated and loaded/unloaded dynamically in the server. NetJack2 is currently limited to LAN, so the real weakness (compared to NetJack1) is the lack of "internet" support for the data transfer protocol. 

Here again, we have to choose the right horse...

> 
> Another thing that has been brought up in the discussion is a standardized driver API for all implementations. IMHO this could have a big impact on jacks future.
> 
> Tobias


JACK2 used a C++ based class hierarchy for drivers. This model allows to share common behaviors in a base JackAudioDriver class. Then real drivers for specific API have to be developed as a subclass of it. See the PortAudio driver as an simple example:

http://trac.jackaudio.org/browser/jack2/trunk/jackmp/windows/portaudio/JackPortAudioDriver.cpp

http://trac.jackaudio.org/browser/jack2/trunk/jackmp/windows/portaudio/JackPortAudioDriver.h

Better documentation is certainly required...

Stéphane 

1323770249.26745_0.ltw:2,a <E3A7636F-FCBD-4053-9FC0-74A557887458 at grame dot fr>