[PD] pd-gui update rate
msp at ucsd.edu
Fri Nov 18 18:41:26 CET 2011
There's no fixed update rate, but Mahieu is right, Pd polls for the
ability to make an update every DSP tick. (one is able to do an update
if the socket from Pd to GUI is writable, i.e., not full).
I've thought for a long time about putting an explicit throttle (on the order
of 5-10 msec) or a flow control mechanism (passing round-trip tokens through
the GUI to see when things are actually getting updated) but have put this
off because of more urgent problems :)
On Fri, Nov 18, 2011 at 11:48:25AM -0500, Mathieu Bouchard wrote:
> 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)?
> Oops !
> 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 fast.
> 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 unrelated.
> 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 sys_flushqueue.
> 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
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
More information about the Pd-list