views:

363

answers:

1

I have a UISlider acting as the scrubber. As the thumb is dragged I execute the following:

- (void) _seekTo:(double)playbackTime {
     mPlayer.currentPlaybackTime = playbackTime;
}

That works fine, music seeks forward. Upon releasing the thumb, I restart the NSTimer to send time updates to keep the UISlider in synch. Problem is, upon releasing the thumb, the first few call backs contain the previous time value. This causes the thumb to jump back to its original position before returning to the new value. Very unsightly.

Anyone have any experience with this behavior and a way to rectify? I can supply a sample project if you would like that demonstrates this anomaly.

+1  A: 

Maybe it’s because there are already decoded data in the buffer when you start seeking. You seek a minute forward, but there’s a few milliseconds of audio in the buffer, and when these buckets play, the player reports their position in the file as current. Only then come the new buckets from the updated position and the marker starts to behave. (Just a theory.)

Couldn’t you simply filter the intermediate data by hand? You know how much you have jumped using the slider, so maybe you could store the new position into a variable and ignore the updates from player until they get comfortably close to the new slider position. (Hope that makes sense.)

zoul
Thanks for the response.That is what I was thinking, but was surprised that the player would not be responsible for the insuring that when you set the currentPlayBack time, that it would do any necessary dumping of cached audio and just carry on from the set location.The filtering idea you propose is something that I was considering prior to this post, but wanted to know if someone had experienced this and if I am missing something obvious. As nowhere in the documentation is there a mention of this, I would lean toward classifying this as a bug or at least poor implementation. Cheers!
Kenny