Re: ExtAudioFileRead sometimes slow on iPhone
Re: ExtAudioFileRead sometimes slow on iPhone
- Subject: Re: ExtAudioFileRead sometimes slow on iPhone
- From: Evan Olcott <email@hidden>
- Date: Tue, 7 Sep 2010 13:05:04 -0500
On Sep 7, 2010, at 12:15 PM, Doug Wyatt wrote:
>> Source audio file is an IMA4 compressed .aif, opened with the ExtAudioFile API. Reading from the file with ExtAudioFileRead into buffers either 128k or 48k (tried both) on a high-priority thread (NOT the CoreAudio thread and NOT the main thread).
>>
>> When the read is going on on this disk thread, occasionally the RENDER thread will starve and stutters will happen. I can confirm that sometimes ExtAudioFileRead takes ~40ms and sometimes it takes >250ms (for the 128k size) and this correlates with the audible stutters.
>
> 128K PCM frames? IMA packets?
128k/48k resulting PCM frames. I'm using ExtAudioFileRead, so I've got that doing the conversion to PCM from the IMA format.
>> AFAIK, I can't check the I/O telemetery like I can on the desktop and I'm hesitant to add log messages to the render thread to find out when it starves,
>
> Well, you *can*, it's just that once you issue your first log message from the render thread, you can trigger a cascade of further failures. You just have to be careful to focus on what leads up to the first failure, since everything that happens afterwards is potentially just side effects.
Interesting. I get the idea of the "cascading" effect, but would it throw a wrench into the works if I said that if I kept reading/playing back the stutters became less and less frequent? Would that sound more like race condition behavior?
Yes, I don't like doing log messages in render threads *at all*, if for no other reason than *everything* slows down appreciably - and understandably.
> You could grab some code from CAPThread (in PublicUtility) to verify that the render thread really is running at realtime priority.
Thanks! I'll look there and see what I can find.
> But in general terms, this kind of issue tends to stem from simply not reading from the filesystem far enough in advance of render time. You might experiment with buffering further in advance.
Even further! ok, I'll experiment with that.
I'm using a double-buffer technique right now and I've playing back from one buffer and loading the other. The buffers are about 3s long each - should I make them even bigger? It seems like it would be enough if the read is even longer than the longest ExtAudioFileRead call at ~250ms.
Thanks for the tip - I'll keep workin on it.
Ev
Senior Software Architect
Audiofile Engineering
http://www.audiofile-engineering.com/
_______________________________________________
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