Emacspeak discussion list

["T.V Raman" <raman AT google.com>]

Responses in-lined.

First a few high-level points:

1. In general, everything in the server should be non-blocking,
2. Exeption: Things added to the queue take effect only after
   "dispatch" is alled.
3. Note that Emacspeak does not implement what is commonly  called
   "indexing" or "bookmarking",
4. This is because the TTS servers are non-blocking and do not wait
   for a response from the TTS engine.
5. This decision was made a long time ago (1994)  and has withstood
   the test of time, though at the time, it was fairly radical.
6. There are some negative consequence, e.g. you cannot sync
   non-speech audio with a given spoken word of output --- but that
   doesn't work well unless the engine itself implements indexing
   (dectalk and outloud do) natively.
7. And if the above is implemented badly, performance suffers.
8. On additional drawback -- mostly relevant if you can see -- the
   visual display in Emacspeak does not track the spoken output.

   Now for specific answers:
   
   

"Robert Melton" (via emacspeak Mailing List) writes:

 > 1. When playing an icon queued with 'a', should it block and wait for 
 > completion or if for example 3 are queued it should fire them off
 > async?
 See above, never block. That said playing them one after another,
 rather than one on top of the other is what I would recommend.
 Icons are meant to be very short, so sequencing should be ok; but the
 > sequenced icons shouldn't block speech.
 
 > 
 > 2. tts_pause and tts_resume are instants correct? Meaning don't wait for 
 > dispatch. 
 >

tts_pause and tts_resume are not used by the lisp code and should be
dropped -- I addedd them at some point in the 90's but decided they
weren't worth the trouble.

 > 3. tts_reset is also an instant correct?  It should stop any output and 
 > reset the tts engine?

Correct. tts_reset is instant.

 > 
 > 4. tts_sync_state questions
 >

Answering tts_sync_state questions in one:

  1. It's mostly there as a hook where you can bring a TTS engine in sync 
with the state on the Lisp side.
  2. Hardware synths need this, software synths dont.
  3. But having it is a good fail-safe.


 > 4a. what is the intention of the dtk-caps value here? Since
 > emacspeak can do the ACC or cap on the lisp side. I copied the 
 > behavior of mac python server using it as allcaps_beep but I am 
 > now unsure if this is correct.

See above.

 > 
 > 4b. I assume this should wait for dispatch and not be instant, 
 > correct?

That "depends" on the underlying TTS engine and how it behaves, likely
safe to not wait for software TTS.

 > 
 > 4c. What is the purpose of tts_sync_state generally, I mean I 
 > understand waht it does, but I don't understand why it is ever 
 > needed.

See above. Also remember that TTS engine can  be multithreaded.


 > 
 > 5. Language settings questions
 > 
 > 5a. What is set_previous_lang and set_next_lang intended to do?

If your TTS supports more than one language, the TTS API exposes these
as a list; these calls loop through the list (dectalk,espeak, outloud)

 > 
 > 5b. What is set_preferred_lang supposed to do, it takes alias and
 > language?

Supposed to pick the default language -- but never tested beyond
English.

--