iOS StreamingKit 'seek' 命令导致音频流报告不正确的进度值

Question

我们正在使用 StreamingKit (https://github.com/tumtumtum/StreamingKit) 从流式 m4a 音频源列表中播放，用户可以在这些音频源之间自由来回移动。

我们记住每个流中的位置，并在项目开始播放时执行搜索(在委托(delegate)方法 didStartPlayingQueueItemId 中)，以返回到该项目的音频中记住的位置。

在搜索之后，音频本身立即移动到正确的偏移量，但报告的时间太大，通常大于轨道的长度。

我发现在 STKAudioPlayer.m 的第 1547 行，delta 有时为负数，这导致播放器在搜索后严重高估了轨道的进度。

我不确定它是如何得到不正确的值的，但出于我们的目的，将这些行包装在 if (delta > 0) { } 子句中可以解决问题。

当排队的项目最近已更改并且播放正在缓冲时，似乎尤其会发生这种情况。

任何人都知道这里发生了什么，以及它是否代表在 StreamingKit 中寻找的错误、我们对如何使用它的误解，或者两者都不是？

Answer 1

我刚刚遇到了同样的问题并使用以下方法修复了它:

https://github.com/tumtumtum/StreamingKit/issues/219

STKAudioPlayer.m 更改:

寻找线:

OSSpinLockLock(&currentEntry->spinLock);
currentEntry->seekTime -= delta;
OSSpinLockUnlock(&currentEntry->spinLock);

并将其包含在 if 语句中以检查 delta > 0

if (delta > 0) {
                OSSpinLockLock(&currentEntry->spinLock);
                currentEntry->seekTime -= delta;
                OSSpinLockUnlock(&currentEntry->spinLock);
            }