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

Attachment: 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

Reply via email to