[CLAM] Re: CLAM digest, Vol 1 #206 - 3 msgs
Stéphane Letz
letz at grame.fr
Fri Sep 23 00:14:30 PDT 2005
>
> Message: 2
> Date: Thu, 22 Sep 2005 20:03:51 +0200
> From: =?windows-1252?Q?Pau_Arum=ED?= <parumi at iua.upf.es>
> To: clam at iua.upf.es
> CC: Stephen Pope <stp at create.ucsb.edu>
> Subject: [Fwd: Re: [Fwd: Re: CSL's ThreadedFrameStream (was Re:
> [CLAM] RT
> and port sizes (was Re: AudioPorts Usage))]]
>
> I'm forwarding this mail from Stephen Pope that didn't get to the list
> (only subscribers can send to the list.)
>
> By the way, Stephen, I'm curious about this networked feature of CSL.
> Do you know jack-udp (a jack udp transport client for the jack routing
> server) ?
> Do you think they both offer the same? I'm interested to learn how
> they
> compare.
>
> Thanks!
>
> Pau
>
From what I know about jack-udp, it is basically a (jack) client
that send/receive to another machine where another jack-udp is
running. Al least this what the initial design. The issue here is
that the 2 machines are synchronized on their own audio card clock,
and without any clock skew detection and correction mechanism, you
can have xrun problems in the transmission after some time.
The second idea that came later was to develop a UDP based driver for
the jack server so that the remote jack server (and clients) get
synchronized by the UDP stream, thus solving the sync problem.
From what I understand about the CLS ThreadedFrameStream/UDP_IO
features, it seems more in the second category.
Stephane
More information about the clam-users
mailing list