[PD] maximum "control rate" in Pd
David Medine
dmedine at ucsd.edu
Thu Mar 12 21:02:18 CET 2015
Yeah, I am realizing now, as I continue to think about this instead of
working, that I don't fully understand this detail.
On 3/12/2015 12:57 PM, Alexandre Torres Porres wrote:
> "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
> <mailto: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
>> <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 <mailto: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 <mailto: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/d977c3b9/attachment-0001.html>
More information about the Pd-list
mailing list