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

[i go bananas]

Hi Chris, and thanks for your input.  Yeah this is for that Link stuff...

Thanks for the explanations and diagrams, and it's pretty much as i
guessed.

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, and as far as i
know, all devices just sync to the slowest one.

The problem is, that messages coming into libPd seem to only be processed
on these multi-block boundaries.  Even with just 10ms or 20ms of samples
per process loop, that's still a lot of drift for something like a drum
machine sending sync every 120ms or whatever.

So to go back to your diagram:

a: >XX|XX|X_|__|*_|__|__|__>

b: >XX|XX|XX|XX|*X|XX|X_|__>

in this case, i would assume that the * message sent to (a) is processed at
the beginning of the next multi-block.

BUT, i would also assume that the * message sent to (b) is also processed
at the beginning of the next multi-block - because:  messages are only
converted to audio on block boundaries. In this case, because you are
processing 8 blocks at once, then messages will only  be processed at the
beginning of the next 8 blocks, regardless of where they appear, or how far
the processing has proceeded.  I just can't see that it could be any
different.

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.

BUT....there is a workaround in pd.  You can use the scheduler, via
[delay], [pipe], [metro] to make sure that messages are triggered in the
audio thread between blocks.
It's that type of behaviour that i want to leverage to make sure that clock
messages are delayed the correct amount in the next block so that we don't
get this wonky sync.  Yes, i understand that means that we have to have
added latency, but as you said Chris,
"You can't really work around physics"

On Wed, Nov 11, 2015 at 11:42 AM, Chris McCormick <chris at mccormick.cx>
wrote:

> Hello!
>
> On 11/11/15 09:18, i go bananas wrote:
>
>> We're trying to implement various sync options in an iOS libPd-based
>> app, and have run across a noticeable drift in the timing.
>>
>
> From Oliver's previous email I guess you're also trying to integrate
> Abelton's "link sync" with your libpd based apps.
>
> https://www.ableton.com/en/link/
>
> The app uses
>> 8 'ticks' of 64 samples for faster devices, and 16 ticks for slower ones.
>> Basically what this means, is that messages are only being processed on
>> these larger multi-block boundaries of 512 or 1024 samples.  And that's
>> not good enough for keeping timing tight.
>>
>> Of course, the first question is:  Has anyone already made a workaround
>> to this issue???
>>
>
> You can't really work around physics.
>
> Or does anyone know of a way to make sure libPd processes messages with
>> proper timing, even with the 'ticks' value set quite high?
>>
>> I have an idea for adding time delay messages to clock signals...so that
>> they can be sent through a [pipe] in pd to arrive at the correct time
>> during the block processing. But it looks quite tricky to implement, and
>> i'll wait to see if there is maybe a better solution first.
>>
>
> I don't think that will work.
>
> From your and Oliver's description (multiple blocks processed at once) you
> seem to be using libpd's PROCESS macro under the hood.
>
> https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L164
>
> Here is a diagram of what is happening (time goes from left to right).
> Hopefully I have this right:
>
> a: >XX|XX|X_|__|*_|__|__|__>
>
> b: >XX|XX|XX|XX|*X|XX|X_|__>
>
>  * The time between the greater than pipe symbols is the real time that
> each block boundary would occur.
>  * The time between the greater than signs is the real time that your
> 8-ticks of one block each would take.
>  * The X's are Pd crunching the numbers to produce output audio for all 8
> ticks in the next set.
>  * The asterisk symbol is a MIDI or other network based event that might
> come in.
>  * You don't hear the audio produced by the X's until the final greater
> than sign.
>
> As you can see in (a) sometimes the number crunching for the entire 8
> ticks is done well before the final greater than sign. Other times, as in
> (b) it only just completes just in time for the audio to come out of the
> speaker, which is presumably why you need to process 8 blocks at once. If a
> sync event arrives, what is libpd and Pd supposed to do? It has to wait
> until the next block of 8 ticks to process the event.
>
> What you propose (using a pipe internally) only delays it within the
> following block so the sync would be even worse.
>
> Your only option is to use less ticks, if you can afford the constraints
> on CPU. In general it's a good strategy to be conservative with regards to
> CPU when doing audio on mobile devices. That might let you get away with
> less ticks.
>
> Hopefully I have this right. If I don't I am sure one of the many people
> on this list smarter than me will correct this. :)
>
> This is all a bit confusing to me because my experience with iOS is that
> one is able to do 20ms block delay/latency quite comfortably for anything I
> have thrown at it.
>
> By the way if anybody is interested in a local-area-network based music
> syncing solution over UDP that is Free Software and unencumbered by
> proprietary licenses, closed SDK, etc. here is a link to the SyncJams
> repository. :)
>
> https://github.com/chr15m/SyncJams
>
> One thing I am super excited about is I heard a rumor that Katja is
> working on a Raspberry Pi based alternative to running Pd on iOS touch
> devices which I imagine should have even lower latency - great for building
> effects units and the like with Pd. I for one welcome our new apple
> crushing raspberries.
>
> Cheers,
>
> Chris.
>
> --
> http://mccormick.cx/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151111/25f42b6e/attachment.html>