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?