I think I was unclear on how I was storing the data... On Thu, Jun 4, 2009 at 2:04 AM, Fred Kiefer <fredkie...@gmx.de> 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
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
