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

Le 14 déc. 2011 à 00:46, Tobias Hoffmann a écrit :

> 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).

OK.

> 
>>> 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.

OK. This is "somewhat" done like that, but can be certainly be improved. I'm open to every proposal.

> 
> The other thing I'm kind of undecided about is the usage of Multicast in netjack2. On one hand it sure has merrits,

It was done like that back in 2008 when we started this work with Romain Moret.


> 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, ...

Could certainly be done with more standard ways.

>> 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?

Yes in some way.

> - to get the audio into jack in this case, the "backend/driver API" is used?

No: an "in-server JACK client" uses the same client API (with some differences to open/close the client). Then it is compiled a a shared lib, (or DLL) and then dynamically loaded in the server.

> - and is it correct to say the big difference between a driver and a client, that the backend/driver provides the timing?

More or less yes.

> 
>> 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.

Make sense. Right now part of this "well-separated pieces" are described as C++ classes or interfaces.

> 
>>> 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.

Sometime C++ inheritance mechanism add more flexibility.

> 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.

I perfectly agree ((-;... Basically I'm proposing a C++ based more modular design and implementation since something like...2005 and after initial war "C versus C++"...  now we are in 2011 and there is still no clear choice of what code base should be used.

> 
> 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

This is a mix of real inheritance base C++ code (for backend/driver), clients... and sometimes use of C++ typing system with a compilation time choice of what actual class has to be used (for server/client communication channels, synchronization primitives....). This is the result of gradual evolution over time, and choice between what C++ virtual method mecanism is helpful for or possibly "removes"  (like some speed in some precise cases..)

But yes, not pure C++.

But the question is still always the same: does the the jack-dev community think the "C code base" can be used to continue development, or the "C++ code base" (even will all it's imperfections that we can discuss and comment forever....., but that we can also gradually improve).

This choice has to be done now.

Stéphane 

1323851465.14087_0.ltw:2,a <1BF970AB-6B3C-4275-ABF0-FBA77D7A28E4 at grame dot fr>