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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
