Re: ExtAudioFileSeek/ExtAudioFileRead issues in iOS4.2
Re: ExtAudioFileSeek/ExtAudioFileRead issues in iOS4.2
- Subject: Re: ExtAudioFileSeek/ExtAudioFileRead issues in iOS4.2
- From: Joel Pryde <email@hidden>
- Date: Wed, 12 Jan 2011 14:47:02 -0800
Ah interesting. I'm guessing you are right on both accounts (and I
did see a bug related to the priming buffer issue).
The strange thing is that setting the priming buffer size definitely
does /something/. If I don't set it, when I do my first read it will
skip the initial part of the file (even though I seeked to frame 0).
If I do set my priming sizes, it will at least do the first read
correctly (and then get screwed up if I try to jump anywhere in the
file).
On Wed, Jan 12, 2011 at 12:52 PM, Ian Esten <email@hidden> wrote:
> My understanding of ExtAudioFileSeek is that it does not do what is claimed by the Apple docs - rather, it seeks to the requested sample location offset by the priming buffer size. If I remember correctly, the priming buffer size is a property of a compressed file. In other words, it is a read only property and cannot be set as you are trying to do. I know I am right about the seek location, but am less sure about the second statement, so you should check that. Also, you are not checking the return code of AudioConverterSetProperty - you may find it returns an error when trying to set the prime info for a read converter.
>
> Ian
>
>
> On Jan 12, 2011, at 12:00 AM, Joel Pryde wrote:
>
>> I've been experiencing a host of issues with the Extended File Audio
>> Services API in iOS4.2 (on iPad in my case). My app allows the user
>> to jump around the audio of a file and converts the localized area of
>> audio from MP3 to PCM using this API. This work great in iOS3.2 but
>> in iOS4.2 the ExtAudioFileSeek function does not reliably seek to the
>> frame I give it. If the audio is read sequentially through a series
>> of seeks (each seek is at the end of my last read) the API function
>> works fine. However if I ever jump to a new place in the file, the
>> audio read out is actually a small amount after where I seeked to
>> (usually around 2000 frames). This exact same code works fine in
>> iOS3.2 so I suspect it was a bug introduced in the audio framework in
>> iOS4.2.
>>
>> I've also had to set the following settings on my AudioConverter to
>> even reliably read the initial part of the file (even when doing
>> sequential seeks):
>>
>> UInt32 primeMethod = kConverterPrimeMethod_None;
>> err = AudioConverterSetProperty (acRef,
>> kAudioConverterPrimeMethod,
>> sizeof(primeMethod),
>> &primeMethod);
>> AudioConverterPrimeInfo primeInfo;
>> primeInfo.leadingFrames = 0;
>> primeInfo.trailingFrames = 0;
>> err = AudioConverterSetProperty(acRef, kAudioConverterPrimeInfo,
>> sizeof(primeInfo), &primeInfo);
>>
>> Has anyone experienced any issues similar to this or know of any
>> workarounds. My next step is to report a bug but I wanted to check
>> here first to see if anyone knew of anything non-obvious that had
>> changed between these versions of the iOS framework.
>>
>> Thanks,
>> joel
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Coreaudio-api mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden