SwiftAudio icon indicating copy to clipboard operation
SwiftAudio copied to clipboard

The "player.currentTime" value returned is incorrect - more so after a seek.

Open SleepiestAdam opened this issue 5 years ago • 1 comments

Describe the bug When you try and fetch the current time using player.currentTime AFTER having seeked a track; it returns a value that is off by < 1%.

By way of example, I played a track with duration 1700.78, seeked to close to the end of the track right away, and once the track ended it reported a progress time of 1682.39 (so off by around 1.1%)?

I've tested both having done a seek and having not done a seek; and the the currentTime appears to be off by a much greater margin when the user has seeked thru the track previously. The attached screenshots show an example of the reported current time and duration when the same track ends both with and without a seek having occurred.

Without A Seek (Off by < 0.03 of a second) Screenshot 2019-11-07 at 12 47 02

With A Seek (Off by around 12 seconds / around 1% of the total track time). Screenshot 2019-11-07 at 12 50 41

The behaviour seems to occur consistently across all the tracks I'm trying to play - which are just regular MP3 files.

To Reproduce See above.

Expected behavior The current time to always be reported correctly.

Screenshots See above.

Desktop (please complete the following information): Catalina

Smartphone (please complete the following information):

  • Device: iPhone X
  • OS: iOS 13

Using the latest Swift Audio (0.11.1)

Additional context I think it might have to do with CMTimeMakeWithSeconds in the seek function and/or could be a rounding issue somewhere? Just guesses...

A quick google also brought up this: https://stackoverflow.com/questions/47158688/ios-11-avplayer-mp3-currenttime-not-accurate so might be worth adding [AVURLAssetPreferPreciseDurationAndTimingKey: true] to the AVURLAsset options just in the hope it sorts it out.

SleepiestAdam avatar Nov 07 '19 12:11 SleepiestAdam

As a workaround for now, it seems it might be possible to set this key without the need to modify SwiftAudio, by creating your own AudioItem class conforming to protocol AssetOptionsProviding? https://github.com/jorgenhenrichsen/SwiftAudio/blob/09a7548f3ac90e2362faa3e27bcff6fbc75830f4/SwiftAudio/Classes/AudioItem.swift#L39-L42

biesbjerg avatar Nov 11 '19 07:11 biesbjerg