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