Frequent "Timer overflowed (late by 0.026s)" warnings on RPi

[aendra-rininsland]

Hi! We've implemented Isobar in kingajanicka/pushpin-groovebox for our sequencers, but we're running into an issue where the clock falls behind and misses a step. Setting root logging level to INFO, we're noticing Isobar emits a "Timer overflowed (late)" log whenever that happens.

Any idea where we should start debugging what's causing that? We're running this on a RPi 5 so it's possible it's something to do with our environment or we're hitting a performance overhead (there's a lot of audio synthesis running alongside Python in our project so I wouldn't rule it out), I'm not sure. Any help would be most appreciated!

[ideoforms]

Hi @aendra-rininsland, thanks for the report! When you say misses a step, do you mean that the timing falls behind, or that some events fail to fire altogether?

Because Python's timing and internal threading has some fundamental limitations, particularly on resource-constrained or heavily-loaded systems, this kind of jitter can be an issue. However, it typically should result in events being slightly laggy, rather than missed altogether. It can also sometimes be remedied, depending on the exact context.

What kind of events are you firing? (e.g, MIDI, or something else?) Are you running the script on the command line or in an IDE?

[ideoforms]

@aendra-rininsland By the way, I will be doing quite a bit of work on this area in early 2025, specifically targeting Pi 5, so you should see a fair few additional features and quality of life improvements that should help with Pushpin. I am particularly adding functionality to support a more traditional groovebox-style use case (tracks containing sequences of static notes, looping regions, tap tempo, and possibly even an undo stack mechanism).

[KingaJanicka]

Hello, other dev here. Right now we're running this in the IDE but we've seen this happen in the command line too. We have Isobar plus a few synths (synths themselves are not python code and our script just launches them via CLI), isobar is sending midi note on/off messages and osc data via the timelime.schedule() command. I don't think the events are dropping, but it feels like a bit of a hickup as the clock tries to catch up from the timer overflow, on slower tempos I remember heading it speed up a little bit before going back to tempo. This is noticable with note on and off, I am not sure if sending messages via osc has the same issues.

We're using Isobar just for clock as I have written my own sequencing logic because we're using push 2 to control this and sequencer state is reflected on the pads. I am wondering if using timeline.schedule is making this clocking issue worse, I remember using the timeline.schedule because I could not find a way to update the sequence once it started playing, but I admit that might have been me not fully understanding Isobar's codebase.