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

PrevNext  Index
DateSun, 13 Feb 2011 20:12:46 +0100
From torbenh <[hidden] at gmx dot de>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToArne Jacobs Re: [Jack-Devel] Jack "capsule/container" implementation?
On Sun, Feb 13, 2011 at 07:57:22PM +0100, Arne Jacobs wrote:
> 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?

cycles are broken, and introduce a period of latency.
the point where the cycle is broken is not specified.

so it basically boils down to a depth first traversal of an acyclic
graph.

> 
> 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
> > 
> 
> Jack-Devel mailing list
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

-- 
torben Hohn
PrevNext  Index

1297624392.16174_0.ltw:2,a <20110213191246.GD16542 at siel dot b>