Question

我们正在使用StreamingKit（https://github.com/tumtumtum/StreamingKit）播放流媒体m4a音频源列表，用户可以在这些音频源之间来回移动。

我们记住每个流中的位置，并且当项目开始播放时（在委托方法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＆gt; 0

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

iOS StreamingKit“搜索”命令会导致音频流报告错误的进度值

1 个答案: