On Fri, 2024-06-14 at 14:16 +0200, Christof Ressi wrote:
The poor man's drop-out detection (and what I do now) is to compare [time] and [realtime]. However, the delta between them varies depending on the configured buffersize. Only if the delta is larger than the buffersize, one can be sure that a drop-out happened.
This method would only somewhat work with the callback scheduler. The very point of the (default) polling scheduler is to allow individual DSP ticks to exceed the audio buffer duration, as long as subsequent ticks can make up for it.
Bad wording on my end. By "buffersize" I meant what you enter into "delay (msec)". However, that's wouldn't be correct either. If [realtime] and [timer] deviates by more than "delay (msec)" + audio blocksize, then you can be sure a drop-out happened (if you're not using the callback scheduler). It might be possible to patch something that more or less reliably detects drop-outs when all the configuration parameters for the audio backend are known, which is possible using the [mediasettings] library.
Roman