SDL_LockAudio lock duration limit under concurrent access

Determine the maximum interval a thread may hold SDL_LockAudio without inducing callback delay in real-time audio playback when multiple threads compete for the audio mutex. SDL's audio subsystem serializes callback execution through an internal mutex; when lock tenure exceeds the audio period—typically 10 to 20 milliseconds—subsequent callbacks may be postponed, generating audible artifacts that manifest primarily under concurrent lock attempts. Documentation does not specify a safe upper bound for lock duration.

This gap creates a design decision point for multithreaded applications that must synchronize audio data across threads while preserving low-latency playback. Without an official threshold, developers must balance lock tenure against the risk of callback delay, with cross-platform scheduler differences further influencing how lock contention translates into observable latency spikes.

What is the maximum lock duration that maintains audio callback jitter within acceptable bounds across common SDL 2.x configurations on major operating systems? Does the safe threshold shift with audio specification parameters such as sample rate, channel count, and buffer size? Are there documented or recommended patterns to achieve thread synchronization without retaining SDL_LockAudio for periods that risk real-time degradation?