Re: NSSound
Stefan Bidigaray a écrit : 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 mailto: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. 24-bits audio becomes very common. Anyway, as Fred said, the format of the data has not to be handle by NSSound : libsndfile do it fine. Just put the audio in a NSData and sndfile will convert it for you. If you use jack (do you ?), i think you only have to call sf_read_float and send the result to jack, that will convert it (again) to a format supported by the hardware. 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 said, I agree with Fred : NSSound has nothing to do with audio format. And I agree with David : this method might be usefull ;) A GSSoundKit might be the right place for it. http://www.cilinder.be/docs/next/NeXTStep/3.3/nd/ http://www.musickit.org/ 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. On debian lenny i386 libsndfile.so is less than 360Kio while libgnustep-gui.so is near 4Mio. If you think it is realy important, what about a reduced libsndfile ? One may probably build sndfile with a reduced set of codecs (the LGPL ones). 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 Regards, - Xavier ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound
Stefan Bidigaray a écrit : On Fri, Jun 5, 2009 at 3:29 AM, Xavier Glattard xavier.glatt...@online.fr mailto:xavier.glatt...@online.fr wrote: 24-bits audio becomes very common. What i mean is that most (all?) sound cards are now 24-bits / 96kHz. Even the old Audigy can do that. (...) A GSSoundKit might be the right place for it. http://www.cilinder.be/docs/next/NeXTStep/3.3/nd/ http://www.musickit.org/ I would really like to go into something like this, I'm actually trying my best to write NSSound in a way that this can be more easily accomplished. I agree ;) That why I think you should Keep It Simple. On debian lenny i386 libsndfile.so is less than 360Kio while libgnustep-gui.so is near 4Mio. If you think it is realy important, what about a reduced libsndfile ? One may probably build sndfile with a reduced set of codecs (the LGPL ones). I mean here that a reduced libsndfile might be included in your code, that will be updated along with the official libsndfile. You would not have to write a fallback NSSound. At least on an audio-capable system. But it might be easier to write your own code - 'dunno. Did you check portaudio ? (just fall on it) It is damn' small! (44Kio) Regards, - Xavier ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound
On Fri, Jun 5, 2009 at 10:45 AM, Xavier Glattard xavier.glatt...@online.frwrote: Did you check portaudio ? (just fall on it) It is damn' small! (44Kio) Yeah, PortAudio is what was being used before in gnustep_sndd (our sound server, which I did away with in the new code). I might have to take a closer look at it, but I'd still like to stay away from maintaining our own sound server, there's already plenty of those out there that are way more powerful than gnustep_sndd was (JACK and PulseAudio come to mind). Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound
On 5 Jun 2009, at 16:45, Xavier Glattard wrote: Stefan Bidigaray a écrit : On Fri, Jun 5, 2009 at 3:29 AM, Xavier Glattard xavier.glatt...@online.fr mailto:xavier.glatt...@online.fr wrote: 24-bits audio becomes very common. What i mean is that most (all?) sound cards are now 24-bits / 96kHz. Even the old Audigy can do that. I didn't reply to this earlier, but I think NSSound should be very wary of making any assumptions about the native sound format for the hardware for several reasons: 1) Expensive hardware now uses floating-point samples internally, and this is likely to become the case for cheap hardware in the future. 2) Handheld devices and telephony systems often use lower quality sound (even 8-bit or 22KHz) for speaker output. 3) A lot of sound hardware can do format conversion in the DSP, which uses less power than doing it on the CPU and doesn't take CPU time from other programs. 4) Any half-decent OS hides these details from you. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound
On 5 Jun 2009, at 16:45, Xavier Glattard wrote: Did you check portaudio ? (just fall on it) It is damn' small! (44Kio) Portaudio just about works on Linux. On other platforms it may occasionally work but is mostly just broken. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound
On Fri, Jun 5, 2009 at 10:53 AM, David Chisnall thera...@sucs.org wrote: I didn't reply to this earlier, but I think NSSound should be very wary of making any assumptions about the native sound format for the hardware for several reasons: 1) Expensive hardware now uses floating-point samples internally, and this is likely to become the case for cheap hardware in the future. 2) Handheld devices and telephony systems often use lower quality sound (even 8-bit or 22KHz) for speaker output. 3) A lot of sound hardware can do format conversion in the DSP, which uses less power than doing it on the CPU and doesn't take CPU time from other programs. 4) Any half-decent OS hides these details from you. David Thanks David, this information is definitely useful. Eventhough I don't like doing so, I think I'm going to want to start over... this time applying all of what we've discussed about here. One thing you mentioned before, which I liked the idea (but wouldn't know where to start) was pushing the NSSound decoding and playing stuff to GNUstep-back (I know you said only output, but if we want to support streaming the decoding is going to have to be done just-in-time). Like I mentioned before, I'm doubting my reasoning behind picking OpenAL as the audio output library. At this point, I think I am a lot better off than where I was 2-3 weeks ago when I started this. Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crash when testing new NSSound
Stefan Bidigaray wrote: OK, so I just finished writing the NSSound code and started testing it. Well, I'm getting to really weird behaviors (one with the fall back and one with the libsndfile code). When using libsndfile, I get a segmentation fault... I stepped through the code and get this: -[NSApplication sendEvent:] (self=0x26cab30, _cmd=0x7fa12efa9ae0, theEvent=0x26fec70) at NSApplication.m:1968 1968} (gdb) -[NSApplication run] (self=0x26cab30, _cmd=0x7fa12ef99540) at NSApplication.m:1468 1468 if (type != NSPeriodic type != NSMouseMoved) (gdb) 1470 [_listener updateServicesMenu]; (gdb) 1471 [_main_menu update]; (gdb) 1474 NS_HANDLER (gdb) 1481 DESTROY (_runLoopPool); (gdb) Program received signal SIGSEGV, Segmentation fault. 0x7fa12de01817 in get_imp () from /usr/lib/libobjc.so.2 Let me know if you need me to go further back. Don't really understand what's happening here. When using the fall back something freezes and my test application's open button never pops back up. Running GDB on that, I can see the problem is whenever I call [isa +_soundIsAU:] in NSSound+AU.m. GDB simply stops responding. I can still click other buttons and quit normally, but it just get hung up on that line. I've attached a copy of my the diff and the sample application (and the .wav file I'm using, that's right bugs bunny). This may no longe rbe relevant, as you are planing to reimplement your NSSound code. Still, when you get a segmentation fault, first do a back trace (command bt) in gdb. This should help to get the information we will need to track down the problem. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crash when testing new NSSound
Yeah, might as well wait! I just realized why I was getting hung on the [isa _soundIsAU:] call (forgot to include the implementation .m file on the build) anyway. The the seg fault can be looked at later. I want to start slowly and actually plan this time around. Last time I just pulled up an editor and started typing, look how well that turned out! I'm going to try to have a proposal sometime soon, then we can go poke holes in it. Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
