Thanks Roman, (see for comments below)
Roman Haefeli wrote: > On Sun, 2009-01-11 at 12:26 +0100, Peter Plessas wrote: >> Timing is a very interesting topic in pd (and with computers in >> general). When i try to measure the [realtime] of a [metro 4] object, i get: >> print: 11.351 >> print: 0.122 >> print: 0.11 >> print: 11.402 >> print: 0.088 >> print: 0.119 >> print: 11.374 >> >> I think you get the same values. Can it be true that there is a >> deviation of 7ms now and then? More interesting: Why is it not only >> now-and-then, but every fourth sample? So there must be some phase shift >> which accumulates in the operation of [realtime]. >> On averaging those values, one gets a value close to 4ms though. >> Does anyone know about the real-life resolution of [realtime]? > > those time steps seem to be related to the audio driver. you seem to run > pd on jack with a latency of 23ms / 512 frames per buffer @ 44.1kHz. > when i use 2048 per buffer at 44.1kHz, i get 92 ms latency and the > numbers look like this: I did this test with -audiobuf 50 running OSS. You are right, the values differ greatly on the kind of audio driver i am using, f.e. with alsa and -audiobuf 50 i get: print: 0.1 print: 4.928 print: 4.991 print: 4.951 print: 4.994 print: 0.098 print: 4.931 print: 4.994 print: 4.949 while using alsa and -audiobuf 100 the result is slightly different as well. And all this while DSP processing is even turned off. > i guess, if you want really accurate realtime values, you would have to > go for the least possible latency, since it seems, that time of > execution of pd is completely dependent on the audio driver. and even if > this would cause drop-outs, the results of [realtime] wouldn't be > affected in a way, that the overall measured time is still valid. if you > use [timer], which measures logical time, and you get drop-outs, all > dropped out time is not part of the measurement and you will get wrong > (too small) values as a result. So realtime is dependent on the audio clock? I always thought that it took the cputime/OS time... I understand that logical time in timer is the internal "perfect" representation of pd's time. > i never understood, why [timer] is giving different values from the ones > that you expected, when connected to a [bang~] inside a re-blocked > subpatch. would be cool to have that either explained or declared as a > bug. Yes, that one is still unclear to me. regards, Peter _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list