Closed PeterEmanuel closed 2 years ago
There's getInLenBeforeOutStart() function available, but if you pass a large-enough audio block, it may return some samples immediately, so it can't be called "latency" in usual terms. Not good to get a fractional output latency, eh? You'll have to arrange a required buffering yourself, this is doable, check this out: https://github.com/avaneev/r8brain-free-src/issues/12
Thank you!
Hi Aleksey,
The comments and explanations in the source code clearly indicate that the resamplers introduce a latency, related to a number of settings, some of which can be tweaked. Then, why is the virtual getLatency() method not implemented/overridden? It now simply returns 0. This is pretty annoying if you want to report latency to the host. There are some hints that the processing can "consume" latency, which of course makes no sense. The internal filters cannot "catch up"... This is also demonstrated by the included example, where empty samples are used to "flush" the last output samples from the filters. My use case is to downsample-process-upsample in the host's callback at high external SRs (above 96 K).
There is internal administration in the resamplers, FIR filter, etc., from which it should be possible to report the current latency... Why not implement the getLatency() method?
Cheers
latency is often difficult to calculate and depends on tons of factors
plugin's and others usually report an ESTIMATED latency, which could be higher, or lower, than the actual latency
@mgood7123 OP was upset that there's no simple way to get a latency, and I may understand the stance from the point of view of e.g. audio plugin developer. r8brain does not feature a buffering loop itself to provide an "inlineable" processing, but that does not mean an exact latency cannot be calculated. I've referenced issue #12 that demonstrates a working buffering loop to use with r8brain-free for inlining.
@mgood7123 OP was upset that there's no simple way to get a latency, and I may understand the stance from the point of view of e.g. audio plugin developer. r8brain does not feature a buffering loop itself to provide an "inlineable" processing, but that does not mean an exact latency cannot be calculated. I've referenced issue #12 that demonstrates a working buffering loop to use with r8brain-free for inlining.
oh cool :)
Hi Aleksey,
The comments and explanations in the source code clearly indicate that the resamplers introduce a latency, related to a number of settings, some of which can be tweaked. Then, why is the virtual getLatency() method not implemented/overridden? It now simply returns 0. This is pretty annoying if you want to report latency to the host. There are some hints that the processing can "consume" latency, which of course makes no sense. The internal filters cannot "catch up"... This is also demonstrated by the included example, where empty samples are used to "flush" the last output samples from the filters. My use case is to downsample-process-upsample in the host's callback at high external SRs (above 96 K).
There is internal administration in the resamplers, FIR filter, etc., from which it should be possible to report the current latency... Why not implement the getLatency() method?
Cheers