How to trigger two programs on two different machines at the sametime?

Hi all,

I hope this is a proper ng to pose my question, could you please point
me to a better one if otherwise?

I need to run two different recording systems each residing in a
separate machine: one acquires audio while the other records video.
Obviously, I want the two resulting streams to be as synchronized as
possible, i.e., they should start recording at the same time.

How good do you think it would be to do this over the ethernet network?
Also, could you suggest a way to program a script that would launch the
recording on the second machine at the same time as the one on the first
machine? Any pointer on where to start studying in order to achieve this?

Thanks in advance for any hints you'll give me.

On Tue, 29 Jan 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <479efe48$(E-Mail Removed)>, Giff wrote:

>I need to run two different recording systems each residing in a
>separate machine: one acquires audio while the other records video.
>Obviously, I want the two resulting streams to be as synchronized as
>possible, i.e., they should start recording at the same time.

"at the same time" is interesting. If you were to look at the
motion picture case, the sound track[s] are recorded on the same
piece of film, but are displaced a set distance because the device
that reads the sound will not fit into the same place as the shutter
mechanism, and that at the instant of displaying the image, the film
is (more or less) stationary in front of the projection light, while
the film is moving at 24 frame/second past the audio detector. This
separation is _about_ 26.5 (optical) or 28 (magnetic) frames ahead
of the picture. The person loading the film onto older projectors
might "miss" the 26.5 or 28 frame point by one frame either way, and
few people watching the movie would notice the error (i.e. 1/24 of a
second mismatch).

>How good do you think it would be to do this over the ethernet network?

Depends on how busy the network and both computers are - PROBABLY not
a problem, but hard to say without details.

>Also, could you suggest a way to program a script that would launch
>the recording on the second machine at the same time as the one on the
>first machine? Any pointer on where to start studying in order to
>achieve this?

It depends on your data recording programs. Off the top of my head, I'd
think of using a wrapper program around your recording applications
such that one application listens for a specific network packet, and
on receiving that delays a calibrated time then starts the recording.
The sending application could be the other recording application,
and it probably also needs a calibrated delay to compensate for it's
own start delays.

Old guy

> On Tue, 29 Jan 2008, in the Usenet newsgroup comp.os.linux.networking, in
> article <479efe48$(E-Mail Removed)>, Giff wrote:
>
>>I need to run two different recording systems each residing in a
>>separate machine: one acquires audio while the other records video.
>>Obviously, I want the two resulting streams to be as synchronized as
>>possible, i.e., they should start recording at the same time.

You do not need to synchronize them, all you need is record an event
that would be clearly seen on video and on sound. Such as clapping
hands. There used to be a special clapping thing in video, two wood
pieces on a hinge that would clap.

i

On Tue, 29 Jan 2008 14:04:25 -0600, Moe Trin wrote:

> t depends on your data recording programs. Off the top of my head, I'd
> think of using a wrapper program around your recording applications such
> that one application listens for a specific network packet, and on
> receiving that delays a calibrated time then starts the recording. The
> sending application could be the other recording application, and it
> probably also needs a calibrated delay to compensate for it's own start
> delays.
>
> Old guy

I wonder if one wrapper could send a message to each of the recording
program's wrappers. The message could contain a time to start recording.
Each of the recording program's wrappers could calibrate itself.
The same main wrapper could start of the feed also.

stonerfish
--
Way over my head.

On 29 Gen, 21:04, ibupro...@painkiller.example.tld (Moe Trin) wrote:

> >How good do you think it would be to do this over the ethernet network?
>
> Depends on how busy the network and both computers are - PROBABLY not
> a problem, but hard to say without details.

Well the computers will only be recording, which is actually a bit
heavy for the one recording video. The network will not be busy, as I
could actually use a crossed ethernet cable and connect the two pc's
directly.

>
> >Also, could you suggest a way to program a script that would launch
> >the recording on the second machine at the same time as the one on the
> >first machine? Any pointer on where to start studying in order to
> >achieve this?
>
> It depends on your data recording programs.

Well the video recording system is made by a colleague of mine so we
have complete control over it, that means I could check how long it
takes from when I trigger it until it writes the first frame (it is
not really video, it's more frame by frame).
I still do not know what to use for the sound recording. It should not
be anything too fancy, just able to record speech and keep it
understandable, we are in a controlled environment (no noise etc.).
For the reasoning below, I should need to know the delay it takes from
the trigger to the actual recording starts... Do you have any
suggestions on what to use?

Off the top of my head, I'd
> think of using a wrapper program around your recording applications
> such that one application listens for a specific network packet, and
> on receiving that delays a calibrated time then starts the recording.
> The sending application could be the other recording application,
> and it probably also needs a calibrated delay to compensate for it's
> own start delays.

So, let me see if I have understood you. If T1 and T2 represent the
time needed by the two applications to actually start recording (I
should then measure these values), and T1>T2, I let machine 2 send
the packet to machine 1 and wait T1-T2 before issuing the start
recording command. This does not count the network delay, but I
measure that too (approximately) and add it to T1-T2.
Am I completely wrong?

Thanks

On 30 Gen, 03:57, Ignoramus1782 <ignoramus1...@NOSPAM.1782.invalid>
wrote:

> You do not need to synchronize them, all you need is record an event
> that would be clearly seen on video and on sound. Such as clapping
> hands. There used to be a special clapping thing in video, two wood
> pieces on a hinge that would clap.
>

Yes, that would be the last resort solution. The problem is that I am
going to record many short clips and then I will have to manually
synchronize them, one by one...

On 30 Gen, 03:58, jellybean stonerfish <stonerf...@geocities.com>
wrote:

>
> I wonder if one wrapper could send a message to each of the recording
> program's wrappers. The message could contain a time to start recording.
> Each of the recording program's wrappers could calibrate itself.
> The same main wrapper could start of the feed also.
>

Yes, that's basically the idea. I posted in order to look for
suggestions on how to implement it.

On Wed, 30 Jan 2008 01:08:51 -0800, Giff wrote:

> On 30 Gen, 03:58, jellybean stonerfish <stonerf...@geocities.com>
> wrote:
>
>>
>> I wonder if one wrapper could send a message to each of the recording
>> program's wrappers. The message could contain a time to start recording.
>> Each of the recording program's wrappers could calibrate itself.
>> The same main wrapper could start of the feed also.
>>
>
> Yes, that's basically the idea. I posted in order to look for
> suggestions on how to implement it.

Suppose you send time n to both recording programs and the feed program.
Then use a calibration feed with a signal (clapping blocks). Start
your feed at n+x, your audio recorder can be set to start at n+y and your
video recorder set to start at n+z. If one of them starts too soon then
make y or z a larger number. If one of them starts too late then make y or
z a smaller number. If they both take too long to start, then increase x.

stonerfish

On Wed, 30 Jan 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <8c693970-601c-4635-8276-(E-Mail Removed)>,
Giff wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

>ibupro...@painkiller.example.tld (Moe Trin) wrote:

>> Depends on how busy the network and both computers are - PROBABLY
>> not a problem, but hard to say without details.
>
>Well the computers will only be recording, which is actually a bit
>heavy for the one recording video. The network will not be busy, as I
>could actually use a crossed ethernet cable and connect the two pc's
>directly.

If the systems are otherwise idle, then the starting delay is going to
be a function of interrupt latency, and the amount of time the
recording programs need to pull their finger out. As the NTP programs
seem to be able to get time data to sub-millisecond accuracy, this
is not likely to be a significant problem.

>I should need to know the delay it takes from the trigger to the
>actual recording starts... Do you have any suggestions on what to use?

I'd probably use a time code generator, or the output of a radio
clock. Use the PPS (Pulse Per Second) output to trigger the start of
the recording. An IRIG-B time stream is a 1000 Hertz audio tone that
is modulated to show time of year. Merely count the number of cycles
between the start of the recording and the next time mark. The audio
output of a DCF77, HBG, or GBR receiver would also work.

>So, let me see if I have understood you. If T1 and T2 represent the
>time needed by the two applications to actually start recording (I
>should then measure these values), and T1>T2, I let machine 2 send
>the packet to machine 1 and wait T1-T2 before issuing the start
>recording command. This does not count the network delay, but I
>measure that too (approximately) and add it to T1-T2.
>Am I completely wrong?

That's the general idea. The accuracy you need depends on what you
are recording, but stuff like broadcast television, or movies
_PROBABLY_ don't need to be sync'ed tighter than 1/25th of a second
(which is, after all, merely two frames of video).

Old guy