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

Stéphane Letz wrote:
>> 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".
>   
Ok, I certainly know more about netjack1 than netjack2. But I'm also 
thinking here about hardware implementations (e.g. VHDL + Soft-CPU).

>> 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: [...]
>   
Thank you. What I meant was, that from my experience with other network 
audio protocols, that there is a "manager" part (maybe with auto-master  
ability by an election protocol), which handles the "who connects to 
whom", and the parameter stuff, and there is the "raw audio transfer" part.

The other thing I'm kind of undecided about is the usage of Multicast in 
netjack2. On one hand it sure has merrits, OTOH I can't stop asking 
myself: do we really need it, are there other ways, etc. And then, if we 
really need it / want it, maybe only for some cases (say, ease of use), 
why not use some standardized mechanisms like multicast DNS-SD, ...
> 2) An "adapter" concept : basically the idea is to "adapt" the network stream on the slave audio system. [...]
> Adapters are also developed as "in-server" JACK clients.
>   
Maybe this questions are stupid (I'm sure lacking good knowledge of 
jacks internals), but I'm not sure I really understand it:
- "in-server JACK client"   is whats essentially called "plugin" in 
other software?
- to get the audio into jack in this case, the "backend/driver API" is used?
- and is it correct to say the big difference between a driver and a 
client, that the backend/driver provides the timing?

> 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...
>   
I'm sure not against netjack2, but my software developer-nature really 
desires to break things down into well-separated pieces with defined 
(internal) API. My way of solving programming problems is by defining APIs.

>> 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.
>>     
> 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: [...]
>   
I'd would like to see a C driver API, but that's only a nuance.
My general intention is to say: Don't think of jack as a monolithic 
entity, but of exchangeable parts, even if we risk even more user 
confusion in the short-term.

And one word about jack2's usage of C++... my feeling, when looking at 
the code, is that jack2 classes are essentially "C code" where every 
method or whatever is packed into some other class, because C++ has 
classes, but not because it makes the structure clearer. The term "C++ 
code" however means to me, that e.g. classes are used, where they 
provide encapsulation of a certain behavior, that C structures and 
free-standing functions are used, where this is the most fitting 
abstraction, templates are used for ..., etc. -- to put it in one word: 
readability

  Tobias

1323820041.877_0.ltw:2,a <4EE7E3F3.9010300 at thax dot hardliners dot org>