I think I was unclear on how I was storing the data...
On Thu, Jun 4, 2009 at 2:04 AM, Fred Kiefer
<address@hidden> wrote:
I think that in almost all cases using NSData is better then storing a
pointer. That way you only have to worry once (when creating the NSData
object) about who is responsible for cleaning up afterwards.
I'll go ahead and use a NSData object to store the data, but to make my life easier on the playback side I only store raw 16-bit PCM data into the object. This allows me to not have to convert it later, and is the native format for most (if not all) sound cards.
Writing in differenet formats should be no concern for NSSound, all we
have to support is writing the data to the pasteboard in a format we are
able to read ourselves.
As for reading we should rely on NSData and have the other two init
methods just create a suitable NSData object. What ever happens inside
of -initWithData: is up to your.
So should I leave -dataWithFormat:fileType: out? And keep the raw reading method (David seems to like the idea)?
As I understand it you are using two different libraries, libsndfile to
read the data and OpenAL to play the sound. As each of them may not be
available on the user system it is great to have fallbacks for that
case. I think it would be enough to support one file format, though.
Well, since the data in all these format are the same, all I really have to worry about is correctly reading the headers. For example, AU can store uLaw, aLaw and 8, 16, 24 and 32 bit PCM in big endian; WAV can store uLaw, aLaw and 8, 16, 24 and 32 bit PCM in little endian. So really, once I can read WAV, I can also read AU as long as I account for the header and convert endian format.
Thanks for the input. I have a lot clearer way ahead at this point. I'll leave the back-end (gnustep_sndd, OpenAL or even JACK now) to after I have a complete, working implementation of the front-end. There are some things that need to be analyzed in some more detail there.
Stefan