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

PrevNext  Index
DateSun, 13 Feb 2011 19:57:22 +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?
I thought about using some graph library first (like from boost), but as
of now I just have a VERY simple proprietary graph structure.

The graph is not really ordered, but execution follows a simple
depth-first search: if some client's input is connected to another
client's output, process that client first... Yes I know it does not
allow for cycles :-) (which I forgot to add to the list of what is not
supported yet). Depth-first search is started at some arbitrary
yet-unprocessed client, after that is finished, another arbitrary
unprocessed client is taken, until all clients have been processed.

I didn't know what is the expected behaviour with graph cycles for JACK,
so I just skipped that for now... can you enlighten me how it is done in
jack1/jack2/tschak?

Cheers,

Arne

P.S.: reminds me that I should probably at least add some kind of check
to avoid making connections which lead to cycles.. :-)

On 13.02.2011 19:50, torbenh wrote:
> 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
> 
PrevNext  Index

1297623473.14191_0.ltw:2,a <4D582992.40207 at gmail dot com>