If the gui thread is holding the lock that the audio thread needs then even a few ms before the gui thread gets a slice (and hands back the gui lock) can cause

If the gui thread is holding the lock that the audio thread needs then even a few ms before the gui thread gets a slice (and hands back the gui lock) can cause the audio to starve and click. I've seen kernels that only time-slice to a lower priority thread if all the high priority threads are sat in a lock. Not ideal but simplifies the kernel code. I've also seen kernels that only context switch when a thread becomes locked or when a (relatively) low resolution timer ticks. (I'm talking non-specifically about the kernels running on video game consoles).