getAudioCallbackLock race condition?

Hello, I’m running into some issues that seem like deadlocks when making calls to set a bpm in an edit’s tempoSequence. It seems like these happen around the call to getAudioCallbackLock() in tracktion_TempoSequence.cpp. Wondering if this is known, and/or if there’s some conventions I should be following in regard to how time changes with the edit should be handled?

How are you setting bpm?

getEdit().tempoSequence.getTempo(0)->bpm ← this is what I’m using and it works without any issues

Yep, that’s what we do as well. I’m wondering if it might be related to async calls to get the transport position at the same time, since those calls also sometimes ask for the same lock I think.

Where is the deadlock happening? If you pause the debugger you should see the two threads that are stuck. Can you post the stack trace please?