[CLAM] Re: CLAM digest, Vol 1 #206 - 3 msgs

[Stéphane Letz]

>
> 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