Re: Math Formula For Playing Sounds

  • From: David Tseng <davidct1209@xxxxxxxxx>
  • To: programmingblind@xxxxxxxxxxxxx
  • Date: Tue, 28 Jun 2011 18:36:15 -0700

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

Other related posts: