SAPI Overview (Windows Embedded CE 6.0)
1/6/2010
SAPI 5.0 consists of two interfaces: the application programming interface (API) and the device driver interface (DDI). The SAPI 5.0 API dramatically reduces the code overhead required for an application to use speech recognition and synthesis, making speech more useable for more applications by more developers.
The SAPI 5.0 DDI and API remove the implementation details such as multi-threading and audio device management making speech synthesis and recognition engines and applications convenient. The SAPI 5.0 interfaces are new and do not use the legacy SAPI 4.0 interfaces.
.gif "Ee484533.0b31dac7-e961-4297-9eac-4ff2dadf72b2(en-US,WinEmbedded.60).gif")
In both speech synthesis and speech recognition, applications receive events. For example, when words of text have been spoken or when phrases of speech have been recognized. SAPI components that generate events implement an ISpNotifySource interface. An application passes to ISpNotifySource::SetNotifySink an ISpNotifySink interface pointer which receives notification calls to ISpNotifySink::Notify when there are one or more events about which the application can retrieve data. Usually, applications will not implement ISpNotifySink because it must be free-threaded. Instead, applications can conveniently use CoCreateInstance (with COM) to make a proxy ISpNotifySink object implemented by the component CLSID_SpNotify. This proxy object provides an ISpNotifyControl interface. It can set up one of three notification mechanisms.
| Method | Description |
|---|---|
Enables a window callback function to receive notifications as window messages. |
|
Enables a callback function to receive notifications. |
|
Enables notifications through Win32 events. |
The ISpNotifySource and ISpNotifySink interfaces only provide a mechanism for a notification, but no information on the events that caused the notification. Using an ISpEventSource object, an application can retrieve information about the event that caused the notification. An ISpEventSource also provides the mechanism to filter and queue events. By default, an application (really an ISpNotifySink) does not receive any notification from ISpEventSource until ISpEventSource::SetInterest has been called to specify about which events to provide notification and for which events repetitions should be queued. Events are identified by the flags SPEVENTENUM.
When an application receives a notification, there may be information on multiple events. By calling ISpEventSource::GetInfo, the ulCount member in the returned SPEVENTSOURCEINFO structure indicates the number of events for which information is available. Using ISpEventSource::GetEvents, an application extracts a specified number of SPEVENT structures, each containing information about a specific event.
This section covers the following topics: