On Sun, 2009-01-11 at 13:42 +0100, Peter Plessas wrote:
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
interesting....
So realtime is dependent on the audio clock? I always thought that it took the cputime/OS time...
i still think, that [realtime] is _not_ dependent on the audio clock (without having read the code). the issue here is the moment, at which the time from OS clock is polled. from what i understand, the pd process is driven by the audio driver, respectively by its clock, so the time, when the 'bang' to [realtime] is executed, is dependent on the implementation of the audio driver. even when not having drop-outs, you wouldn't know exactly, when [realtime] polls the system clock. this could be somewhere between now (0ms) and chosen latency. that is why you get the jitter, when measuring with [realtime].
i once could make use of this two different time measurement methods to tune the jack-server running with the dummy driver to the correct samplingrate.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de