1

I am working on an iOS MPEG-DASH player and I have an issue with seeking feature.

ExtAudioFileSeek(::) documentation said

Sets the file’s read position to the specified sample frame number. A subsequent call to the ExtAudioFileRead(::_:) function returns samples from precisely this location, even if it is located in the middle of a packet.

Unfortunately, the AudioToolbox.AudioFile_ReadProc loop does not seek straight to the right frame and goes trough all file segments, requesting 16 and 27682 bytes packages. It takes a lot of time (especially for long tracks) and force to download all intermediate segments (that should not be required) This also cause the app to crash when long tracks with high sound quality are being played.

Here my log trace. I converted frame index to "mega" for more readability.

[PlayerEngine] - Trying to seek at 16.870537 % 
[AudioSource] - Pausing AudioOutputUnit 
[AudioSource] - AudioOutputUnit successfully stopped 
[AudioOutputUnit] - Trying to seek at frame 31.006805M 
[AudioOutputUnit] - Successfully sought at frame 31.006805M 

[AudioInputUnit] - Audio frames have been flushed 
[AudioInputUnit] - Seek to frame 31.006806M pending 
[AudioConverter] - Converted frame buffer has been flush 
[AudioSource] - Resuming AudioOutputUnit 

[AudioSource] - AudioOutputUnit successfully resumed 
[PlayerEngine] - Successfully sought at 16.870537 % 
[AudioInputUnit] - Seeking to frame 31.006805M 
[CoreAudioDecoder] - Trying to seek at frame 31.006805M 
[CoreAudioDecoder] - Seek on frame 31.006806M done successfully 

[CoreAudioDecoder] - AudioToolbox.AudioFile_ReadProc : inClientData, inPosition:1.315635M, requestCount:16
(...)
[CoreAudioDecoder] - AudioToolbox.AudioFile_ReadProc : inClientData, inPosition:1.331687M, requestCount:27682

Is it a bug on AudioToolBox or is there a way to fix it ?

Thanks a lot !

Renaud Codarini
  • 11
  • 1

1 Answers1

0

Cool!

Since you mention read callbacks, I assume you're using not only the ExtAudioFile API but also the AudioFile API as well, something like ExtAudioFileWrapAudioFileID(AudioFileInitializeWithCallbacks(...))

Compressed audio formats don't always have a simple mapping between frame and file offsets and so the naive behaviour you're seeing is probably due to one of these APIs (AudioFile?) understandably not knowing this mapping.

Try either setting the kExtAudioFileProperty_PacketTable property on the ExtAudioFile or kAudioFilePropertyPacketTableInfo on the wrapped audio file. The former probably makes more sense. I don't know if the whole packet table info will be available to you from the beginning or if it will be revealed to you over time, nor how the APIs will react to you setting these properties multiple times.

Good luck!

Rhythmic Fistman
  • 34,352
  • 5
  • 87
  • 159