Agreed on the async part though that's exactly why Cocoa as a framework provides callbacks and the app just needs to register for them. I certainly would not want my app to block every time I'm playing a sound. It's not too hard to get a worker thread to go off and play the sound especially in higher level environments like .Net. As for sound processing, I don't see any problems with running an in-memory buffer of the clip through a third-party library that would let you apply effects. On 6/28/11, Jamal Mazrui <empower@xxxxxxxxx> wrote: > An asynchronous callback is better, if practical, but does add > significant complexity. In fact, unfortunately, almost whenever > multithreading is involved, complexity increases exponentially. Of > course, it may be necessary to achieve performance or multi-user > objectives, but the risks should be well-understood as well. > > Regarding the JAWS API, I do not think that the built-in COM server > includes methods for adjusting speed, volume, or pitch. There may be > functions, however, that can be called by the JFWRunFunction method, > which accomplish the same objective in a more dynamic manner. Not sure. > > Jamal > > On 6/28/2011 7:30 PM, Andreas Stefik wrote: >> Callbacks are definitely nice, but not all API's support them. The Mac >> API is probably the best one out there. Microsoft's API is actually >> pretty good as well. Both have their annoyances, however, and >> limitations. With other tools it just goes downhill quickly. >> >> Since Jamal appears to be listening to this thread, did you ever >> figure out a way to make the JAWS COM API change pitch, volume, speed, >> or something similar? >> >> Stefik >> >> On Tue, Jun 28, 2011 at 6:23 PM, David Tseng<davidct1209@xxxxxxxxx> >> wrote: >>> I would imagine that MFC or .Net at least has some facility to either >>> play a sound sync or async with a callback. In the former case, you'd >>> probably want the work to be done on a separate thread which is why >>> the callback's preferable imo. >>> >>> On 6/28/11, Jamal Mazrui<empower@xxxxxxxxx> wrote: >>>> I think some sound APIs allow one to play a sound file synchronously -- >>>> so that the call to the play-sound function does not return until the >>>> sound has completed playing. It's been a while since I looked at the >>>> code, but if memory serves, the SayTools COM server offers such a >>>> function call. Of course, SayTools would have to be registered on the >>>> client computer -- though it is freely distributable. >>>> >>>> Jamal >>>> __________ >>>> View the list's information and change your settings at >>>> //www.freelists.org/list/programmingblind >>>> >>>> >>> __________ >>> View the list's information and change your settings at >>> //www.freelists.org/list/programmingblind >>> >>> >> __________ >> View the list's information and change your settings at >> //www.freelists.org/list/programmingblind >> >> > __________ > View the list's information and change your settings at > //www.freelists.org/list/programmingblind > > __________ View the list's information and change your settings at //www.freelists.org/list/programmingblind