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:
parent
0262df7c53
commit
43b6a504b8
2 changed files with 18 additions and 0 deletions
|
@ -25,6 +25,8 @@
|
|||
- (void)process;
|
||||
- (AudioChunk * _Nullable)convert;
|
||||
|
||||
- (double)secondsBuffered;
|
||||
|
||||
@end
|
||||
|
||||
#endif /* DSPRubberbandNode_h */
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue