[PD] maximum "control rate" in Pd
Charles Z Henry
czhenry at gmail.com
Thu Mar 12 21:58:12 CET 2015
On Thu, Mar 12, 2015 at 3:18 PM, David Medine <dmedine at ucsd.edu> wrote:
> Yeah, of course. Block size 1 and high sampling rate will make the timing
> between control and audio super tight (ChucK does this, for example). It
> will also eat the hell out of your CPU. It's a trade off. This is because
> you start calling all the DSP functions once every 1/192k seconds instead of
> once every 1.45ms.
This last sentence is also a misconception--the dsp tick function is
called every 64 samples, as commonly defined.
sys_time_per_dsp_tick = (TIMEUNITPERSECOND) *
((double)sys_schedblocksize) / sys_dacsr;
sys_schedblocksize gets set from DEFDACBLKSIZE
So, the dsp_tick gets called, and when there is a sub-patch with
[block~ 1], it loops over the graph generated from the sub-patch 64
times.
You'd find this behavior coded with the block prologue and epilogue functions.
>
> On 3/12/2015 1:06 PM, Alexandre Torres Porres wrote:
>
> Well, anyway, I was hoping for a simpler answer, and my original guess was
> that the control rate limit might be at the block size, now I'm all confused
> :)
>
> I'm seeing that maybe we can't really measure the speed efficiently in a
> patch, and that Pd might actually be able to manage tiny and fasty clocks,
> but that there is also a limit on the way they are computed that depends on
> the block size, right?
>
> What about a block size of one, and a large sample rate? I wonder if we
> could get control messages to work at 192Khz for example, huh?
>
> One way or another, I guess there might be a pretty straightforward answer
> to this. I didn't find any in Miller's book yet.
>
> cheers
>
> 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
>>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
More information about the Pd-list
mailing list