Re: [Jack-Devel] Jack "capsule/container" implementation?

On Sun, Feb 13, 2011 at 07:15:44PM +0100, Arne Jacobs wrote:
> Hi again...
> 
> I gave it a try and made a first proof-of-concept JACK wrapper. The JACK
> clients I made so far all compile and run nicely with it. However I
> stumbled upon some things in the JACK API which are not quite clear to
> me from the documentation. Maybe you can help me with those?
> 
> - The function jack_port_disconnect(jack_client_t*, jack_port_t*) makes
> me wonder what it should really do. The documentation doesn't help me,
> because it says it performs the same function as jack_disconnect(), but
> I can't see how it could with those parameters...?
> 
> - jack_port_type_id_t jack_port_type_id(const jack_port_t *port):
> This is totally unclear to me. It seems to be in my JACK header but it's
> not in the online documentation. Probably I can just ignore that?
> 
> - jack_port_get_total_latency(jack_client_t*, jack_port_t*):
> The semantics of this is not quite clear to me. Would I be correct to
> assume that (given none of my wrapped clients introduce any latency) I
> could just call this on my wrapper client's input and output ports and
> take the maximum of all?
> 
> - Can there only be one error/info function at the same time? It seems
> so to me...
> 
> - Regarding MIDI buffers: how large are these typically? Currently I
> make them the same size as the audio buffers (i.e.,
> sizeof(jack_default_audio_t) * nframes bytes)...
> 
> Apart from that, if there is any interest in this subject I could try to
> compile that stuff into some little library for those who would like to
> test it out.
> 
> Not the whole JACK API is implemented right now, though. What is not
> supported yet:
> - anything regarding latency (I just return 0 latency in any related
> function)
> - anything regarding monitoring (I guess this has no place in a wrapper
> anyway)
> - port lookup using regular expressions (didn't look for a low-footprint
> regex-lib here yet)
> - setting error and info handlers (wouldn't make sense anyway if there
> could be only one of each at any time)
> - some callbacks are not called yet (only client and port (un-)register,
> connection and process callbacks so far)
> - port types other than the default MIDI and audio types
> - port aliases
> 
> Also, all wrapped clients are running in the same process thread
> (because they are considered one single client by the JACK server). The
> wrapper client currently also supports only one audio input and output
> as well as one MIDI input/output.
> 
> And the last limitation: of course you can't use any JACK control app to
> make the connections between the wrapped clients. They have to be done
> programmatically. Well, in theory you could link e.g. patchage to the
> JACK wrapper and use it for all wrapped connections, but this seems a
> bit too much effort :-).
> 
> But like I said: proof of concept...

hmm... interesting. 
how are you doing the graph sort ?

> 
> Cheers,
> 
> Arne
> 
> Jack-Devel mailing list
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

-- 
torben Hohn

1297623065.13461_0.ltw:2,a <20110213185049.GC16542 at siel dot b>