On 08/17/2010 02:11 PM, João de Brito Rocha Reis Vidigal wrote:
Hi
I remember reading somewhere that it is possible to have 2 Pd patches open
running synched at the same time.
This would be to manage sound and video in different patches in order not to
get (or get less) glitches in sound and video.
How do I do this?
Depends on what you mean by synched.
Well of course you need to run two instances of Pd as if it was two
different programs.
If you mean using one patch (in one pd instance) for audio and the other
(another pd instance) for video, which is i think the only solution to
get both audio and video work well, I usually synchronize them by
exchanging messages through [netsend]/[netreceive] pairs, via either TCP
or UDP.
I would periodically send a packet from audio patch to video patch to
tell it the current time. The video patch would then compare it with its
own time. If the difference (measured in frames) is above a certain
threshold, it would use some strategy to correct the situation in the
least disturbing way depending on the application.
In the most simple case, you would detect if the difference in frames is
>1 (or <-1) and you would wait or skip the necessary number of frmaes.
Depending on the application, you may need much less than that (or a bit
more).
For example, when you have to start playing an audio and video clip at
the same time (which may be an audio and video file or the generation of
images and sound), you just send one message from the "master" (e.g. to
the audio patch) to the "slave" (e.g. the video patch) so they would
start at the same time. If the audio and videos you're playing or
generating are short enough (few minutes) you may even not observe
significant desynchronization. If you do, then you can resort to the
above strategies to correct it.
All depends on the precision you need.
I usually use audio as a master and video as a slave because slightly
affecting the speed of the video (or even skipping a frame) for
resynching is usually much easier and more acceptable than doing the
same on the audio side - but of course it depends.
Well I'm kind of assuming you're using GEM for the video; GEM is pretty
good at maintaining a reliable timing; if it gets slow because of CPU
load for a limited period of time, it tries to compensate it when it
can, so it tends to not accumulate big errors soon.
Is this what you were talking about?
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
