[PD] maximum "control rate" in Pd
Alexandre Torres Porres
porres at gmail.com
Thu Mar 12 20:57:20 CET 2015
"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."
I got less in a mac with pd vanilla 0.46-5 64 bits, tried 1e-08 on [delay]
and it was not accurate, [timer] giving me around 9.73e-09
then tried even lesser numbers and [timer] stopped 1.08126e-09
2015-03-12 16:42 GMT-03:00 David Medine <dmedine at ucsd.edu>:
>
> 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>:
>
>>
>>
>> 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>>:
>>>
>>> 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>>>:
>>>
>>> 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>> 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> <
>>> 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> 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> 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
>
>
>
> _______________________________________________
> 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/0969e5c6/attachment-0001.html>
More information about the Pd-list
mailing list