The synthesizer is not idle. RRS feed

  • Question

  • Hi,


    I am trying to play a prompt in speech server, stop that prompt and then play a different prompt.  I am trying to do this using the synthesizer.SpeakAsync and SpeakCompleted events.  I am doing this using a parallel workflow activity.


    In my first activity, I wire up my events and start the first prompt.  In the second prompt it goes off and does some work and then comes back and does a SpeakAsyncCancel() to cancel the initial prompt.  This all seems to work fine, but when I try and do a SpeakAsync on my next prompt I always get "The synthesizer is not idle" error message?


    Does this mean that the synthesizer is still hooked into the first prompt and it never really got cancelled?  (i.e., the cancelled event just fired when the async request was sent but not actually completed?).


    Any comments or ideas would be great.


    Thanks - Greg.



    Monday, May 5, 2008 8:56 PM

All replies


    Try using a SpeechComposite Activity when accessing the synthesizer.
    Tuesday, May 6, 2008 1:01 AM
  • You need to wait[1] for the SpeakCompleted after invoking SpeakAsyncCancel. 




    [1] Not literally, i.e. don't block the thread.  If you haven't already, look at SupervisedTransfer sample application for how to write custom speech activities.

    Tuesday, May 6, 2008 9:22 AM
  • Hi Anthony,


    I am waiting for the SpeakCompleted to fire after invoking SpeakAsyncCancel before calling the method to do another TTS prompt.




    Tuesday, May 6, 2008 11:43 AM
  • The Synthesizer state is set to Idle before invoking SpeakCompleted, so you should be able to invoke SpeakAsync from within or after the SpeakCompleted event handler.  If you can't, then something else must have caused the state to become non-idle. 


    From the etl logs, look for ApplicationInterfaceEvent; this will show invocations to ISynthesizer methods / events, which will allow you to track down if you're e.g. accidently calling SpeakAsync twice.  An easy way to introduce such a bug would be to wire a handler up to SpeakCompleted multiple times.


    In the debugger, you could also put a breakpoint where you invoke SpeakAsync and look at the private State property on ITelephonySession.Synthesizer.

    Tuesday, May 6, 2008 2:28 PM