Re: NSSound

[Fred Kiefer]

Stefan Bidigaray wrote:
> OK, I've been staring at the structure of NSSound as I have it now (not
> like the one in the tar.gz I sent out before) and I think I need to take
> a step back and design this a little better.  I need some help!  One
> thing to keep in mind is I will not go into the playing back-end since
> that still needs to be vetted.  I'll try to tackle each on at a time:
> 
> 1 - NSData ivar
> As can be seen in the tar.gz and .diff (in savannah) I modified the
> ivars.  The question here is, should I have replaced NSData with a data
> pointer and length like I did or should I have kept the NSData?  My
> reasoning was merely due to overhead, and the fact that I can only read
> and play pointers anyway.
> 
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.

> 2 - New, helper methods
> Libsndfile allows me to very easily do virtual I/O (all I have to do is
> implement length, read, seek, write and tell), so I initially moved the
> reading code to -initWithData: and used [NSData
> -initWithContentsOfMappedFile:] in [NSSound -initWithContentsOfFile:]. 
> As I moved on, I figured it would be nice to be able to write to file
> and read from raw PCM data (both easily supported using libsndfile).  I
> went ahead and created two new methods:
> -initWithData:raw:range:format:channels:sampleRate:byteOrder: (moved
> reading to here and had -initWithData call it instead) and
> -dataWithFormat:fileType:.  What do you guys think of this?
> 

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.

> 3 - Fallback implementation
> The tar.gz attached includes a dive into some fallback methods to read
> WAV and AU (possibly AIFF/AIFF-C) data even when libsndfile is not
> available.  I modeled it somewhat after the NSBitmapImageRep code, where
> I have 2 new files (NSSound+WAV.m and NSSound+AU.m) + a bunch of helper
> functions to read the data (in NSSoundPrivate.h).  Initially I thought
> this wasn't going to add much code, but it looks like between all the
> new file and actual reading it comes out to quite a bit of new code. 
> The question here: is it worth it?
> 

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.

> If it would be better to have an organized meeting on this I can log
> into the IRC channel, just tell me the time best for you.

Sorry, I don't like IRC and find mail that much easier as it allows me
to work asynchronously.

Fred