@weightless for me it seems to be a more or less constant difference of about 5 ms. metro speed does not affect this.

delay 20:

delay 60:

Let's hope the bug is just in realtime or it is the os that is too lazy to report the time in time.

This patch seems to indicate this, but not definitely: realtime-test.pd

For me it looks like whenever the time is exactly zero, either realtime or the os is too slow to report the actual microseconds difference. Which would be good news for the delay and pipe objects.

This patch seems to indicate the same: delay-test.pd

Instead of adding up, the differences roughly stay within the 5 ms margin.

For now my conclusion would be that delay and pipe are ok, but one should not rely on time measurement too much.

The source of the error could be realtime, os or hardware, which is still not determined in my view.

@ingox I think so too, that the object work fine. This test seems to show that the bang from [pipe 98] goes through every time (there's an offset of 1 don't know why).

@weightless confirmed, the delays are completely in sync: delay-test2.pd

Yes I get the feeling the delays are OK but [realtime] isn't!

@nuromantix Looks like it. I get inconsistent results with this too:

@weightless I think [realtime], and all the other bits are correct and "ok"...... but of course every object and every connexion has a time associated. Looking at it a few days ago I found that changing the order of connections, saving and re-opening a patch, introducing a common [bang]..... etc. all influence the scheduling.
David.

@whale-av That's good to know!

the delays will always be "in sync" because they run on logical time not realtime... there is a difference between the 2
you can use [timer] to measure logical time