[PATCH 4/7] replace EVoiceType with SPDVoiceType

[Hynek Hanke]

On 5.11.2010 21:58, Andrei.Kholodnyi at gmail.com wrote:
> yes, however in the current implementation we map SPDVoice type 
> individually for each module,

In current SSIP, this is consistent with having a SSIP SET OUTPUT_MODULE
command. Having SET VOICE behave unrelated to the SET OUTPUT_MODULE
would be very confusing.

> whereas IMO we should map it to all voices present in SD, apps do not 
> need to know about modules.

Ideally yes. The output module handling the given voice could be a property
of the voice in our high-level API and modules could be switched according
to the particular voice desired. The client application would thus not 
need to care
about modules at all if it didn't want to, just about voices.

There are practical considerations however. The modules/TTS systems are not
different just in the voices, but in their capabilities, ways of 
handling things etc.
SSML defines a (very useful and needed) possibility to switch 
language/voice inside
the piece of text being processed. It is not however possible to switch TTS
systems inside text (because of earlier stages of processing like 
prosody etc.)
and because of the different capabilities.

Thus the voices selected in SSML would be mapped to different physical
voices than the ones selected in SSIP, although the selection criteria would
be the same. This is inconsistent and confusing.

Further, I think the whole idea of having different concurent TTS systems
for different voices languages is not really technically justified on the
Free Software platform.

Best regards,
Hynek Hanke