Re: [PD] maximum "control rate" in Pd

David Medine Thu, 12 Mar 2015 15:02:02 -0700

@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 thismight lead to a misunderstanding.

Also, I see that suseconds_t (which is the type of now.tv_usec) is aninteger, as I had previously thought, so I am really perplexed as to how[delay] can apparently deliver bangs within less than 1us. I would lovefor someone to explain this to me. It is a small detail and it doesn'treally matter in practice, but I am annoyed when my inferences are notcorrect -- 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 <dmed...@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 <dmed...@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 <c...@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 <c...@chnry.net
<mailto:c...@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 <c...@chnry.net
<mailto:c...@chnry.net> <mailto:c...@chnry.net <mailto:c...@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@lists.iem.at <mailto:Pd-list@lists.iem.at>
<mailto:Pd-list@lists.iem.at <mailto:Pd-list@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@lists.iem.at <mailto:Pd-list@lists.iem.at>
<mailto:Pd-list@lists.iem.at <mailto:Pd-list@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@lists.iem.at <mailto:Pd-list@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@lists.iem.at <mailto:Pd-list@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@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list



_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list



_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list



_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] maximum "control rate" in Pd

Reply via email to