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