Re: audio priority and multitasking on iOS
Re: audio priority and multitasking on iOS
- Subject: Re: audio priority and multitasking on iOS
- From: Ian Esten <email@hidden>
- Date: Tue, 30 Nov 2010 16:34:48 -0800
On Nov 29, 2010, at 11:33 AM, Niels Bogaards wrote:
> - my callback does some reading via AVAssetReader's copyNextSampleBuffer. Is this a no-go in the callback? If so, what would be the preferred approach; reading (very) much in advance on a normal thread (like the main thread), or create/hook into another high priority thread like the quicktime thread (and would that thread still run when the app is in the background?).
This is a no-go. Reading from disk can block. Create a thread that reads into a big buffer in memory and copy from that in your callback.
> - I use an NSLock tryLock in the callback. Is this ok? would a pthread mutex/condition be better?
The thing that matters most here is that you have your locks set up such that the RemoteIO thread does not get blocked.
> - I use vDSP in the callback. Is that ok? Are there compiler flags I should set to have optimal vDSP performance?
This is a good thing to do. You are spending less time in the RemoteIO callback.
Basically, you should never do anything in the RemoteIO callback that takes an indeterminate amount of time to execute.
Ian
_______________________________________________
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