[PD] maximum "control rate" in Pd
David Medine
dmedine at ucsd.edu
Thu Mar 12 20:42:24 CET 2015
My understanding of this patch and the guts of Pd tells me that this
patch isn't really going to measure how long it takes between each
control message. What it can do is show the time resolution of calls to
sys_getrealtime, which is Pd's method of querying the CPU clock:
double sys_getrealtime(void)
{
#ifndef _WIN32
static struct timeval then;
struct timeval now;
gettimeofday(&now, 0);
if (then.tv_sec == 0 && then.tv_usec == 0) then = now;
return ((now.tv_sec - then.tv_sec) +
(1./1000000.) * (now.tv_usec - then.tv_usec));
#else
LARGE_INTEGER now;
QueryPerformanceCounter(&now);
if (nt_freq == 0) sys_initntclock();
return (((double)(now.QuadPart - nt_inittime.QuadPart)) / nt_freq);
#endif
}
The code is from s_inter.c. It is apparent (at least in the non-Windows
part of the code) that there is a microsecond resolution, hence 1e-6,
but I could misunderstanding this. I was able to put 1e-7 on a Windows
machine and it still worked -- I haven't had a chance to do try it in
Unix/BSD land and I don't actually want to know what Windows is doing
with this QuadPart of a LARGE_INTEGER. Still, (on Linux and Mac, anyway)
1us is the smallest unit of time that Pd's clocks keep track of, so that
should be the limit of what [delay] can do.
The actual time it takes for Pd to deal with messages depends on a great
many things. Symbols in Pd are stored in a hash table, so I would guess
that the size of the table (which needs to be searched) is the main
factor controlling the rate at which those messages can be handled.
However, I suspect that the number of symbols needed to slow Pd down on
a modern computer is impractically large. Then there are control
messages that don't have hashed symbols associated with them (like
floats and bangs). Also, some external controls -- especially
mouse/keyboard events and MIDI -- can be badly timed. These tend to
queue up and get spit out at the OS's whim. Pd then simply does what it
can with what it gets. So measuring the exact time it takes to /do/
control in Pd is pretty hairy. I don't believe that meaningful
measurements of this can be done with a Pd patch.
The other thing is that control messages get rolled up between dsp ticks
and are then applied immediately on the start of the next tick. This
means that two messages that are, say, .05ms apart somewhere in the
midst of a 1.45ms block, get applied simultaneously at the start of the
next block. This also means that at 44.1kHz with a block size of 64
samples, both of them may be anywhere from 0.02 ms to 1.45ms late --
depending on where they fall in relation to block boundaries. This also,
also means that if one control message happens near the end of one block
and the other happens near the start of the next block, their distance
of .05ms in physical time will be expanded to 1.45ms. This is a very
big, teeny-tiny problem in real-time audio programming because under
certain conditions there can be serious (audible) repercussions. This is
why there is [vline~], by the way.
If anyone else is interested in this stuff, I recommend these lectures
(Miller's is the first in the series):
http://repmus.ircam.fr/mutant/rtmseminars
-David
On 3/12/2015 10:25 AM, Alexandre Torres Porres wrote:
> > timer and realtime compute 2 different things
> > (logical time and real time). i don"t know what
> > your want.
>
> I know they are different, and I don't really know what I want either :)
>
> I just wanted to measure how long it takes between each control message.
>
> you were using [realtime], and then Roman came in and said that'd be
> kinda random and how [timer] was best for it. So I tried with [timer]
> and got a very nice result indeed. But I'm not sure now if that
> actually relates to whats going on... or how it is actually working.
>
> > what i don't understand is your intention with
> > the spigot in the patch.
>
> just wanted to have a way to close the message stream, but you can
> forget about it
>
> cheers
>
> 2015-03-12 14:14 GMT-03:00 Cyrille Henry <ch at chnry.net
> <mailto:ch at chnry.net>>:
>
>
>
> Le 12/03/2015 18:04, Alexandre Torres Porres a écrit :
>
> "/i don't understand your patch.
>
> using [timer], a delay 0 will give a 0 delay...
> logical time will always be consistent./"
>
> well, I thought you were disucussing here and reaching the
> conclusion that [timer] is the one to be used to calculate this...
>
> timer and realtime compute 2 different things (logical time and
> real time). i don"t know what your want.
>
> what i don't understand is your intention with the spigot in the
> patch.
>
> cheers
> c
>
>
> So you mean this result is actually inconsistent? And the
> implication is that it is not going at that super fast rate at
> all? Please help me understand better about how to measure this.
>
> thanks
>
>
> 2015-03-12 11:55 GMT-03:00 Cyrille Henry <ch at chnry.net
> <mailto:ch at chnry.net> <mailto:ch at chnry.net
> <mailto:ch at chnry.net>>>:
>
> hello,
>
> i don't understand your patch.
>
> using [timer], a delay 0 will give a 0 delay...
> logical time will always be consistent.
>
>
> cheers
> c
>
>
> Le 12/03/2015 15:41, Alexandre Torres Porres a écrit :
>
> ok, so the metro at 1ms is because I'm using extended.
>
> as for the minimum time pd can process and send data,
> what's the final word on it?
>
> something like 1.4013e-45 ms?
>
> cause that's a lot more than an audio rate at 44.1khz :)
>
> I thought there was a limit control rate that was
> below the audio rate, but curiously it can go over.
>
> 1 sample at 44.1khz gives us 0.0226757 ms, and I was
> able to send bangs at 1e-06 ms, according to [timer]
>
> check my patch attached, based on the one that was
> sent here on the thread.
>
> thanks
>
> 2015-03-12 10:04 GMT-03:00 Cyrille Henry <ch at chnry.net
> <mailto:ch at chnry.net> <mailto:ch at chnry.net
> <mailto:ch at chnry.net>> <mailto:ch at chnry.net
> <mailto:ch at chnry.net> <mailto:ch at chnry.net
> <mailto:ch at chnry.net>>>>:
>
> hello,
>
> Le 12/03/2015 10:12, Roman Haefeli a écrit :
>
> On Thu, 2015-03-12 at 09:17 +0100, Cyrille
> Henry wrote:
>
> hello
>
> this patch show the same behaviors for a
> delay based metro and a [metro].
> (both can do faster than 1ms period)
>
>
> You're right. More recent versions of Pd (>=
> 0.45?) have an updated
> [metro] that supports many more ways to
> specify time and the restriction
> was lowered. However, the [metro] in any
> available version of
> Pd-extended is still limited to 1ms.
>
> sorry, i was not aware of this old limitation.
>
>
> I don't understand why you use [realtime] and
> not [timer] to illustrate
> your point. [timer] gives you consistent
> values (logical time) while
> [realtime] is very jittery and shows just
> some random value depending on
> the current cpu usage and probably other
> factors. When you render a
> soundfile, the logical time is actually the
> one that matters.
>
> yes, for things that stay in pd, logical time is
> better.
> but if you want to send midi note, [realtime] is
> more related to what happens.
> it's just the way i understand the original question.
>
> cheers
> c
>
>
>
> Roman
>
>
>
>
> ___________________________________________________
> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>>>
> mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/____listinfo/pd-list
> <http://lists.puredata.info/__listinfo/pd-list>
> <http://lists.puredata.info/__listinfo/pd-list
> <http://lists.puredata.info/listinfo/pd-list>>
>
>
> ___________________________________________________
> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>>>
> mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/____listinfo/pd-list
> <http://lists.puredata.info/__listinfo/pd-list>
> <http://lists.puredata.info/__listinfo/pd-list
> <http://lists.puredata.info/listinfo/pd-list>>
>
>
>
>
> _________________________________________________
> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>>
> mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/__listinfo/pd-list
> <http://lists.puredata.info/listinfo/pd-list>
>
>
> _________________________________________________
> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>>
> mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/__listinfo/pd-list
> <http://lists.puredata.info/listinfo/pd-list>
>
>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150312/82201504/attachment-0001.html>
More information about the Pd-list
mailing list