gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSSound Reimplementation


From: Stefan Bidigaray
Subject: Re: NSSound Reimplementation
Date: Thu, 11 Jun 2009 16:13:20 -0500

OK, this has been out for almost a week now and I think it's time to start responding to some of the comments/suggestions brought up.

CHOOSING INPUT/OUTPUT DEVICE
This is a pretty reasonable request, specially since it's part of the API (check -setPlaybackDeviceIdentifier:), the problem here is that I'm not sure what to expect!  I don't have a Mac, and the API only explains that the input must be a NSString ("Unique identifier of a sound output device.").  I can say right away that Libao doesn't not support this feature.

STREAMING
David, I can see where you're coming from, however, since 10.5 NSSound uses either CoreAudio or QTKit to play sound ("... this class may use either Core Audio or QuickTime to handle the actual playback."), meaning NSSound can be used for this purpose.

THREADING
I guess I just want to make sure that I'm allowed to use threading on the core GNUstep libraries?

I didn't see a single objection to libao and the plug-in based architecture.

In my head, I've split NSSound into 4 different parts: NSSound: will manage the other 3 "modules"; GSSoundThread (NSThread subclass): will do the actual streaming; <GSSoundInput>: a category that will define a standard interface to read audio data; <GSSoundOutput>: same as GSSoundInput but for output.  The attached text file is my first attempt at defining how NSSound will communicate.

I've been reading up on NSThread and it would seem that since 10.5 NSThread can be subclassed, override -main and call -start to start the thread.  Will I be allowed to use this mechanism?

As always, all comments/suggestions are welcome and appreciated.

Stefan

Attachment: NSSound_arch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]