Hey all
The Pd main window has an indicator for audio I/O errors that flashes red whenever it detected a buffer underrun. Is that information exposed in a way it can be accessed in a patch?
If not, would that be a worthwhile feature? I think: yes.
A patch using audio input for recording could immediately tell if the recording is garbage, for instance.
My current use case is for clocks: When a drop-out is detected, it is a good moment for re-syncing the clock as the steadiness is lost anyway at that moment and the drop-out is basically the only reason for clock drifts.
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. Having that info reliably from Pd directly would be definitely better.
Roman
Roman, good idea! Note that there is some kind of check for audio discontinuities in 7.stuff/tools/latency.pd as well.
- Roman Haefeli reduzent@gmail.com [2024-06-14 09:36]:
Hey all
The Pd main window has an indicator for audio I/O errors that flashes red whenever it detected a buffer underrun. Is that information exposed in a way it can be accessed in a patch?
If not, would that be a worthwhile feature? I think: yes.
A patch using audio input for recording could immediately tell if the recording is garbage, for instance.
My current use case is for clocks: When a drop-out is detected, it is a good moment for re-syncing the clock as the steadiness is lost anyway at that moment and the drop-out is basically the only reason for clock drifts.
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. Having that info reliably from Pd directly would be definitely better.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi,
On 14.06.2024 09:35, Roman Haefeli wrote:
Hey all
The Pd main window has an indicator for audio I/O errors that flashes red whenever it detected a buffer underrun. Is that information exposed in a way it can be accessed in a patch?
Currently no.
If not, would that be a worthwhile feature? I think: yes.
I think so too!
In the polling scheduler we already do handle xruns (by zeroing the buffers), so just need to also report it the patch. This can be easily done with an atomic integer counter. I might give it a shot.
In the callback scheduler things we are the mercy of the audio backend. AFAICT, portaudio does not provide any API to report xruns. Jack, on the other hand, allows to install an xrun callback (https://jackaudio.org/api/group__ClientCallbacks.html#ga08196c75f06d9e68f9a3...), which we could use for this purpose.
Actually, this feature would be quite handy for my AOO library. I have an API method to report xruns, but I can't really use it yet on Pd because I don't get the xrun information.
A patch using audio input for recording could immediately tell if the recording is garbage, for instance.
My current use case is for clocks: When a drop-out is detected, it is a good moment for re-syncing the clock as the steadiness is lost anyway at that moment and the drop-out is basically the only reason for clock drifts.
Side note: this is only true on the same machine. Different machines have sightly different audio clock speeds that also drift over time. That might be a problem, or not. That's why AOO, for example, offers dynamic resampling to compensate for clock drift effects.
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.
Having that info reliably from Pd directly would be definitely better.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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
-
Christof Ressi -
Peter P. -
Roman Haefeli