@DusX I promised to get back around on this, and now I have! Thanks to @mark's latest developments, I can now visually illustrate this issue. Note how the general service task is well within bounds for most of these tests, and yet the only delay value that seems to actually impact my results is the final jump, from 10ms of delay to 100ms. At 60FPS with a 30x General Service Task, we should be updating roughly every 1.8ms, so I understand why 1ms and even 2ms could cause issues, but 5? 10? and the general lack of improvement when moving from 1 to 10? That seems like there is some spike of activity after the first value is received preventing subsequent values from propagating.
The reason this will eventually matter is that the user may have hundreds of participants on the call, and with roughly 100ms between list replies in the initial setup, a 600 person Zoom call could take over a minute to get Isadora up to speed. I am using the new control to illustrate, but there are other uses unrelated to control where this could be a larger issue.
(Ignore duplicated usernames, the 100ms result is the expected result).
Thanks for the bug report. This bug was in 2.6.1 as well... I guess no one encountered it before. I've fixed it in v3 and the fix will appear with the next point release (3.0.2) which is coming shortly.