[PD] maximum "control rate" in Pd

David Medine dmedine at ucsd.edu
Thu Mar 12 23:01:03 CET 2015


@Charles: None of those five sentences is a misconception. When I said 
'DSP functions' I meant the functions of the form 
'whatever_tilde_perform', not the dsp tick function. I see how this 
might lead to a misunderstanding.

Also, I see that suseconds_t (which is the type of now.tv_usec)  is an 
integer, as I had previously thought, so I am really perplexed as to how 
[delay] can apparently deliver bangs within less than 1us. I would love 
for someone to explain this to me. It is a small detail and it doesn't 
really matter in practice, but I am annoyed when my inferences are not 
correct -- especially when I send them to the Pd list!

On 3/12/2015 1:58 PM, Charles Z Henry wrote:
> 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