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

Paul Davis wrote:
> But part of the reason to endorse a C++ implementation was to
> make things much more modular, and although Jack2 superficially looks
> that way, in practice in seems not to be.
>   
This is also my impression of the code.
>    >    realtime device switching (without stopping/restarting server)
>   
Ok, but that could imply changing basic Jack parameters like the period 
length, samplerate, etc.

But of paramount importance from a user standpoint is, that either jack 
*never* crashes[1] or every application has to be able (e.g. forced by 
jack API) to reconnect after a jack server died.

>    >  single header file tree, for use by jack1, jack2 and anything else
>   
IMO applications should be programmed to a extensively documented Jack 
API[2], and not to a certain implementation. If we then want ABI 
compatibility a common header tree is the only logical conclusion. But 
still there have to be mechanisms for API versioning and/or feature 
detection.
There also has to be a well-defined and not overly cumbersome procedure 
for extending the API.

> You're also ignoring the need to have a single netjack streaming
> protocol, 
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], ...).

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. And there are people out there that would be 
willing to connect via netjack, but without using jack at one end -- 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".


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

[1] big problem here until I discovered "Soft Mode"
[2] e.g. what has to be expected in a jack_midi_event_t

1323727590.28103_0.ltw:2,a <4EE67AD2.4000205 at thax dot hardliners dot org>