Minor Bug Fix: Handle Rubber Band buffer latency

We implement this function to return the current latency buffered,
regardless of how often this function may be called. In practice, it is
only called on track completion, to time the reporting of the next track
display. We also avoid using Rubber Band's latency function, as in most
cases, this function will be called from other threads, and also, it
currently only gets called after Rubber Band has been emptied out, so it
would otherwise calculate zero samples buffered. And thirdly, Rubber
Band's latency function doesn't account for the buffered samples already
removed from it and waiting to be fed out.

Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This commit is contained in:
Christopher Snowhill 2025-02-16 14:06:15 -08:00
parent 0262df7c53
commit 43b6a504b8
2 changed files with 18 additions and 0 deletions

View file

@ -25,6 +25,8 @@
- (void)process;
- (AudioChunk * _Nullable)convert;
- (double)secondsBuffered;
@end
#endif /* DSPRubberbandNode_h */

View file

@ -513,4 +513,20 @@ static void * kDSPRubberbandNodeContext = &kDSPRubberbandNodeContext;
return outputChunk;
}
- (double)secondsBuffered {
double rbBuffered = 0.0;
if(ts) {
// We don't use Rubber Band's latency function, because at least in Cog's case,
// by the time we call this function, and also, because it doesn't account for
// how much audio will be lopped off at the end of the process.
//
// Tested once, this tends to be close to zero when actually called.
rbBuffered = stretchIn - stretchOut;
if(rbBuffered < 0.0) {
rbBuffered = 0.0;
}
}
return [buffer listDuration] + rbBuffered;
}
@end