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

PrevNext  Index
DateSun, 13 Feb 2011 19:15:44 +0100
From Arne Jacobs <[hidden] at gmail dot com>
To[hidden] at lists dot jackaudio dot org
In-Reply-Totorbenh Re: [Jack-Devel] Jack "capsule/container" implementation?
Follow-Uptorbenh Re: [Jack-Devel] Jack "capsule/container" implementation?
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...

Cheers,

Arne
PrevNext  Index

1297620969.8936_0.ltw:2,a <4D581FD0.1070503 at gmail dot com>