You could try if (far less powerfull than Gem) Pof externals could suit your needs, cause the GPU thread is decoupled from the audio thread. Not sure that the available deken version will work on 18.04 though...



Le lun. 1 oct. 2018 à 12:54, Roman Haefeli <reduzent@gmail.com> a écrit :
On Mon, 2018-10-01 at 12:15 +0200, Csaba Láng wrote:
> Thanks for the hints, probably the best idea is to turn off dsp every
> time it is not needed. However playing a video and audio with metro
> control (sending the bangs according to the frame rate) and using
> cameras in the same time makes pd totally loose sense of time. Very
> disappointing, as I trusted more in metro than in God.
> Popesz


Pd is designed to be deterministic. There is no notion of skipping some
task in order to keep synchronicity with real time, unlike many media
players that are able to skip frames in order to playback a movie file
with no interruption.

It has been discussed many times on this list about how to deal with
audio and video in Pd. Probably the best way is to run the audio and
video part in two separate instances of Pd, whereas the audio instance
does all the time-critical stuff and the video part is controlled by
the audio part through some communication channel (network socket, unix
socket, [pd~], etc.).

Roman


> On Sun, Sep 30, 2018 at 9:23 PM Jean-Marie Adrien <
> jm.adrien.mnt@gmail.com> wrote:
> > mabye you could set dsp on (and off again if needed) this will
> > synchronize pd in a more reasonable way
> > … and keep an eye permanently on this aspect if time measurement is
> > critical for ur patch
> > (high load might blow pd out, means 1 second is lasting three
> > seconds or so, in this latter case there is little to do besides
> > optimizing the patch)
> > JM
> >
> > > Le 30 sept. 2018 à 20:55, Csaba Láng <langcsaba@gmail.com> a
> > écrit :
> > >
> > > Dear list,
> > >
> > > how is it possible that measuring a metro 1000 with realtime
> > object i get 333.3 as a result?
> > > I am testing it on an Ubuntu 18.04 and time just goes 3 times
> > faster than it should.
> > > On a Mac OS the result for the same test is expectedly 1000ms.
> > > Please advice!
> > >
> > > Popesz
> > > _______________________________________________
> > > Pd-list@lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > https://lists.puredata.info/listinfo/pd-list
> >
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list