AudioIPC processes cubeb operations sequentially on the server event loop. When a potentially slow operation (e.g. stream_init or stream_stop) is in progress, all other operations are queued behind it - including fast, latency-sensitive operations like stream_get_position on unrelated streams.
This means a single stream performing a slow stream_init (e.g. waiting for PulseAudio to connect) or a blocking stream_stop (e.g. waiting for a drain timer to fire) can cause audio glitches or position reporting stalls on other, otherwise healthy streams.
AudioIPC processes cubeb operations sequentially on the server event loop. When a potentially slow operation (e.g. stream_init or stream_stop) is in progress, all other operations are queued behind it - including fast, latency-sensitive operations like stream_get_position on unrelated streams.
This means a single stream performing a slow stream_init (e.g. waiting for PulseAudio to connect) or a blocking stream_stop (e.g. waiting for a drain timer to fire) can cause audio glitches or position reporting stalls on other, otherwise healthy streams.