Thanks Iohannes

So, i can conclude that the slaves local frame clocks are taken from the "local" gemhead objects, as explained in Matteo's answer ? Is it more reliable/light than using a metro on each computer (which would allow me to change the playback speed) ???

Also, for the codecs, no, i don't have raid system. And it's mostly laptops with slow drives. But i'm not sure to have some spare cpu to treat a compressed video codec.




2010/1/28 IOhannes m zmoelnig <zmoelnig@iem.at>
changed the subject back to the original mail...

Marco Donnarumma wrote:
> Yep, I can confirm the same. I worked with three macs connected via LAN and
> a simple sync via a master works very well.

this will usually give you quite a lot of jitter, since the "now" in Pd
drifts in the audio-buffer (network jitter is probably neglectable in a
LAN, but of course you also have that), which most likely will lead to
not so smooth playback.
of course it depends on the material you want to play back.

the solution we came up with, was to have a master frame clock and local
frame clocks on the slaves.
the slaves would adjust their framerates in order to keep up with the
master, if the lag between the master clock and the slave clocks was low
(some frames).
if the lag was too big, the slaves would "jump" to the target value.

this worked well with several "full size" (cannot remember the actual
resolution) videos played back in sync with live and taped music over 90
minutes or so.

> Also, maybe someone could disagree, but in my experience not-compressed
> movies (even full DV) are lighter for the machine.

uncompressed video is lighter for the CPU, but more load for the
harddisk. the "best" codec always depends on your system (e.g. do you
have a fast RAID-system?)

fgmasdr
IOhannes



--
http://www.myspace.com/nicotep
www.bedroomresearch.com/TEP
http://nicotep.free.fr