[AG-TECH] Audio losses synch (more technical questions)

[Ivan R. Judson]

The latest CVS version of the common lib portability issues have been
resolved.  I've submitted the fixes to the folks with cvs access to put
them in the tree.  Dunno if they've made it in yet or not, but they will
eventually I'm sure.
 
--Ivan

-----Original Message-----
From: owner-ag-tech at mcs.anl.gov [mailto:owner-ag-tech at mcs.anl.gov] On
Behalf Of Robert Olson
Sent: Monday, June 10, 2002 7:49 AM
To: s.booth at epcc.ed.ac.uk; White, Derek [NCSUS Non J&J]
Cc: Nolan, Kevin [NCSUS]; ag-tech at accessgrid.org
Subject: RE: [AG-TECH] Audio losses synch (more technical questions)


We typically don't run with lipsynch activated between rat & vic
(reasons include the necessity to play with .mbus files to get the
synchronization to work properly between audio and display machines, the
fact that vic's synch support is indeed out of synch with the support in
rat, and that when on a good-quality network, the casual synchronization
resulting from best-effort transmission results in "good-enough"
lipsynch).

All that being said, if you get this working that'd be great, and we
should look at integrating the fixes.




At the moment this would not be enough to fix a standard AG node, if
audio
and video sources are from different machines the cnames will not match
anyway as these are derived from the IP address.


We've had some other discussion lately about changing the AG stuff to
define CNAMEs on a per-node rather than per-host basis.



I managed to compile up the AG vic code linked against the most up to
date 
UCL common library. (There is some new crypto code that has been
seperatly added to both development trees but if you delete the files
from vic the program still links ok)


An aside on why this is there - vic doesn't use the libcommon mechanisms
for RTP transport (it has its own internal RTP handling code). The
crypto code that's in libcommon is there in support of rat (and other
clients of the libcommon RTP library). Vic has analagous crypto code in
a module conforming to the vic crypto interface.



 This might be enough to fix this
problem. It should be as all the mbus code would be from the same
revision.


Did you see any weirdness with vic built with the latest libcommon? if
not, we can go ahead and merge the new libcommon in with vic. 

Did you use the CVS version, or the latest release version (1.2.8). Ivan
found some win32 portability problems in the latest CVS version; not
sure of the state of resolution of those.

--bob


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/ag-tech/attachments/20020610/88e7449b/attachment-0001.htm>