Re: CoreAudio vs CoreData
Re: CoreAudio vs CoreData
- Subject: Re: CoreAudio vs CoreData
- From: patrick machielse <email@hidden>
- Date: Thu, 13 Oct 2011 23:54:30 +0200
Op 13 okt. 2011, om 23:17 heeft Hank Heijink (Mailinglists) het volgende geschreven:
>> 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.
The CoreData document will always remain quite small. I use an xml type store, which should load the data model entirely into memory. That should keep the chance of slow disk access.
> 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.
The document is essentially a list of managed objects modeling a file. Each file has a path (alias data) and associated settings such as playback speed, inital playback offset, etc. etc.
As an example consider this situation:
Each file has an associated 'volume envelope'; an array of points describing file-playback-volume(time). These points are stored as a set of managed objects in the CoreData document. While playing back the document, the current playback volume must be interpolated from these envelope points for each file on each render callback. This might / will translate to a fetch of these points. -[NSManagedObjectConttext executeFetchRequest:] requires locking when performed from multiple threads.
Another interesting scenario is manipulating the volume envelope during playback. So far that seems to work well, but whith threading issues that can be very deceiving and it's good to be suspicious about your code…
Thanks,
p.
--
Patrick Machielse
Hieper Software
http://www.hieper.nl
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