[PD] libPd timing issue, seemingly caused by processing multiple 'ticks' of audio blocks.

[Chris McCormick]

On 11/11/15 14:45, i go bananas wrote:
> But i don't think you properly see what my workaround does.
>
> See, the problem is not with latency, per say...because the Link
> framework has that covered...so we can have quite a bit of latency,

Yes you're right, if they are doing latency compensation then the most 
important thing is consistent latency. In that case, doing a [pipe] or 
[delay] hack should hopefully work.

> So, what you get, is this system where messages are only processed in
>  the audio thread every time that multi-block boundary is
> reached....just as messages in pd itself are just added to the audio
> thread on block block boundaries.

Yep, I think that's right.

SyncJams is implemented in Pd itself so I don't have this issue - 
everything happens in the correct logical time without [pipe] hacks etc.

 > and as far as i know, all devices just sync to the slowest one.

The algorithm that SyncJams uses is quite simple:

  1. All nodes keep their own internal metronome (integer counter).
  2. All nodes broadcast their metronome counter value every tick.
  3. If a node ever receives a metronome value that is *higher* and 
*earlier* that its own metronome, it immediately jumps to the incoming 
metronome's phase + value. Higher & earlier is treated as always "more 
correct".

The effect of this is that all nodes sync to the fastest network ping 
time that is experienced during a session. So if the network has a 
general latency of 10ms but some packets sneak through in 3ms then the 
sync difference will be 3ms. The overall effect is that sync gets 
tighter over time monte-carlo-asymptotically towards the optimal 
possible latency given the hardware. It also means there is no 
master/slave setup and that the metronome that every node is syncing to 
is the virtual "consensus" metronome that emerges from the network 
rather than one specific node having the best or most correct clock.

Each node assumes it is not the best node, and thereby the group 
benefits during consensus.

Cheers,

Chris.

-- 
http://mccormick.cx/