[PD] pd-gui update rate
matju at artengine.ca
Fri Nov 18 17:48:25 CET 2011
Le 2011-11-18 à 09:34:00, Roman Haefeli a écrit :
> Ah.. I was actually looking for the number 14112000, but of course I
> didn't look for 32. * 441000. But then, 14112000 / 5000 gives 2822.4 Hz,
> which would be a too high rate for GUI refresh. So, what is relation
> between the tick and 5000 that leads to a sane GUI refresh rate (and
> finally, what _is_ the GUI refresh rate)?
sched_tick handles the span of time of one hardware dsp block, and I think
that this is usually frozen to be 64 samples regardless of sampling rate
(for 44100 Hz, this is 1.45 ms). the while() loop looks for all upcoming
clock events ([metro], [delay], [pipe], etc) and processes them until the
time of the next dsp block.
The 5000 might be never used. You'd need 5000 [metro] or [delay] objects
being activated between two consecutive dsp blocks. In addition to being
very unlikely, it's also nearly impossible to do : if 5000 objects put
5000 things in the clock queue in chronological order, this takes 12.5
million loops per clock tick, and each loop is 3 comparisons and 2
assignments. No CPU has the time to do it in one tick. Pd doesn't have to
be like that, there are good datastructures that it could use, but it
does not use them, so it's extremely inefficient at some things when those
things appear in large numbers.
You can get well over 5000 clock activations in one dsp tick, but you have
to do it in other ways. you need a self-connected [delay] with an
extremely low number, because [metro] won't let you make a [metro] that
Anyway, I don't get it, I mean I don't get the existence of the 5000. My
previous answer about 14112000 was a mistake : the number is correct but
Instead, sys_pollgui is called almost only from m_pollingscheduler...
It looks like it's called at every dsp tick (1.45 ms) but inside
sys_pollgui it calls sys_domicrosleep which is actually a function that
checks all filehandles for incoming data, and if there's no incoming data
in a given tick, then sys_poll_togui is called. That one, in turn, checks
whether the output buffer is empty, and if it isn't, then it doesn't call
So, the answer seems like it's that pd refreshes the gui using a clock of
689 Hz, and the fastest possible GUI updates would be half of that, but
Tcl never keeps up with that, so it slows down the rate by just not
reading enough stuff that pd sends it, and pd skips calls to
sys_flushqueue in those cases.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
More information about the Pd-list