Re: CoreAudio vs CoreData
Re: CoreAudio vs CoreData
- Subject: Re: CoreAudio vs CoreData
- From: patrick machielse <email@hidden>
- Date: Mon, 17 Oct 2011 21:39:56 +0200
Having thought about it a bit more, I think we'll keep using CoreData in our CoreData application for the time being.
CD access should be fast enough under most circumstances:
- Our CD model will always be very small; no binary objects, just simple properties.
- We're using the XML store type so the data will be loaded entirely into memory.
Our application is an audio editor. Playing back audio isn't the main feature; although pretty important it's not as crucial as in an application that is purely designed for playback. As such, it would be acceptable if hitting a lock in a render callback would cause a small stutter, _occasionally_.
Also, it occurs to me that not using CoreData would not solve the entire problem. While some of the hidden 'CoreData' magic would be taken out of the (processing) loop, we would still have to design 'lock free' access to our data from the render thread while the user may be editing the project settings from the main thread.
I would be interested in links / resources on how to devise such a lock free access scheme.
Thanks for all of your valuable input,
patrick
--
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