[PD] precise milisecond/second counter

[Roman Haefeli]

hi ilya

On Tue, 2007-11-20 at 04:52 +0000, ilya .д wrote:
> hello list.
> 
> i was terribly surprised the way [metro] behaves -
> 
> checking it agains [timer] of coruse doesn't give any latency ever!

[metro] does its job accurately in logical time. it's not accurate, if
a) you have audio dropouts
b) you are using it to generate some output different from audio and you
measure the output (e.g arduino)
c) if you are using [realtime] to measure, because [realtime] measures
in realtime, which means, that it measures the moment, when the output
of metro is processed. this can happen anywhere between now and
audiobuffersize later, depending on your cpu load.
 
when you use [metro] to trigger a sound and you record the result, then
you will see, that it is even subsample accurate (if your sound
generation part is based on [vline~] and not on [line~]). you will also
see that [metro] is just perfectly accurate in logical time when
measuring with [timer], which actually measures logical time.
 

> but with [realtime] and [cputime] - the result is is far from acceptable
> and even unproportional, (icresing twice doesn't give any aproximatable
> result).

when taking the average, the output of [realtime] should be change
proportionally to the change of [metro]'s time. if not, the only
explanation i have is that your running pd over the limit of your cpu,
which shifts logical time against real time (this happens with every
drop out).


> how ever the system load was quite hight -
> /proc/loadavg: 3.29 3.31 3.54 6/268 22074
> and even > 5.0  at some point..

yo, what i was saying.

> i run linux 2.6.20 with built in RT_MUTEX ..
> i never noticed any latency while interacting via gui..
> how ever there was a bit of acceptable audio latency when i was
> programing some effects using live input and comparing to pd's streight
> wire from adc~ to dac~ (inside a busy patch) there was a noticable delay ..

the delay is in no way related how busy pd is. 

> however i assumed [metro] to be closer to ideal , really ..

as long as you are dealing with audio, [metro] _is_ ideal. the reason
why this works so well with audio is, that pd's timing is based on a
fixed rate, which is the clock of your soundcard (respectively jack, if
you are running pd with jack, but jack takes the clock from the card
then...). when your output is only a soundfile, you even don't need a
soundcard to get perfect results, [metro] is still perfectly accurate,
no matter at which speed the file is calculated. 

> so i have actually made a patch which give a very precise ticking.

your [bang~]/[block~] based solution does - as [metro] - work in logical
time, thus is expected to give you the exact same results.  

> please have a look ..

you forgot the attachment.



	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de