Re: CoreAudio vs CoreData
Re: CoreAudio vs CoreData
- Subject: Re: CoreAudio vs CoreData
- From: "Hank Heijink (Mailinglists)" <email@hidden>
- Date: Thu, 13 Oct 2011 17:17:15 -0400
On Oct 13, 2011, at 5:05 PM, patrick machielse wrote:
> Hi,
>
> I'm currently involved in the developement of an audio processing application which uses CoreAudio. In a nutshell it construcs a AUGraph on the main thread which is then played back by AUFilePlayer.
>
> The played audio files and processing settings are stored within a document using CoreData. The upshot is that the high priority audio thread will access managed objects in read / render / processing callbacks.
>
> So far we've encountered some problems: CoreData isn't very threading friendly, locking the NSManagedObjectContext from the render thread seems a sub-optimal solution.
That's putting it mildly. Accessing Core Data objects involves (possible) database access, which involves (possible) file system access, and all of these operations can cause the thread to block. Blocking the audio rendering thread is a recipe for trouble.
Why do you need to interact with CoreData in your rendering thread? If you give us a bit more information, we might be able to suggest an different way to achieve what you're after.
Best,
Hank
_______________________________________________
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