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