Re: NSSound

[Fred Kiefer]

Hi Stefan,

I only had a quick glance at your new code. I definitely support the
idea of supporting the new MacOSX methods on NSSound, but haven't had
the time to see, whether there is a way of supporting them with the old
openaudio interface. What I don't understand is what we gain/loose by
giving up our own sound server?
I will look into all this in more detail, but there is already one thing
I noticed that needs to be changed in your code. You changed the
encoding/decoding in a non compatible way and also did not change the
version of the class. Could you please fix this?

Fred

Stefan Bidigaray wrote:
> Well, I've been messing with NSSound for a few weeks now and got to the
> point where, in order to continue, I need some help.  I posted a few
> patches up on Savannah, but as I kept working on a fall back code for
> whenever there's no libsndfile (the patches I put up was based on it,
> and the fall back can currently read AU/SND and WAV in PCM 8, 16, 32
> bit, uLaw and aLaw [I'm planning on 32 and 64 bit float soon]) I pretty
> much ended up having to rewrite most of NSSound so that it can now
> respond to -initWithData:.  I've somewhat hit a point where I need
> someone to take a look at what I've done so far and let me know if I'm
> going in the right direction or not.
> 
> I've also started branching out a bit from the Apple docs and introduced
> a -dataWithFormat:fileType: which allows data to be written to a NSData
> object in any of the formats that I can read in.  I thought it would be
> nice having the ability to convert between different file types.  I'm
> also think about adding a method to read RAW PCM data, which wouldn't be
> very hard and would allow for NSSounds to be created from raw CD data,
> and in combination with the previous method write it to file (pretty
> much all you would need to create a CD ripper would be someway to read
> the CD data, which I thought would a good idea).
> 
> I'm attaching the files I worked on.  A diff of this stuff is huge, so I
> thought it would be easier to just attach the files themselves.  I still
> haven't done any work on AIFF/AIFF-C, but plan on taking a look into it
> soon.  AIFF poses a problem (for me at least) because of that stupid
> 80-bit IEEE float representing the sampling rate, where as the others
> are just straight integers.