kspeech Class Reference
kspeech - the KDE Text-to-Speech API. More...
#include <kspeech.h>
Public Types | |
enum | kttsdJobState { jsQueued = 0, jsSpeakable = 1, jsSpeaking = 2, jsPaused = 3, jsFinished = 4 } |
enum | kttsdMarkupType { mtPlain = 0, mtJsml = 1, mtSsml = 2, mtSable = 3 } |
DCOP Member Functions | |
DCOP Methods | |
virtual bool | supportsMarkup (const QString &talker=NULL, const uint markupType=0)=0 |
virtual bool | supportsMarkers (const QString &talker=NULL)=0 |
virtual ASYNC | sayScreenReaderOutput (const QString &msg, const QString &talker=NULL)=0 |
virtual ASYNC | sayWarning (const QString &warning, const QString &talker=NULL)=0 |
virtual ASYNC | sayMessage (const QString &message, const QString &talker=NULL)=0 |
virtual ASYNC | setSentenceDelimiter (const QString &delimiter)=0 |
virtual uint | setText (const QString &text, const QString &talker=NULL)=0 |
virtual int | appendText (const QString &text, const uint jobNum=0)=0 |
virtual uint | setFile (const QString &filename, const QString &talker=NULL)=0 |
virtual int | getTextCount (const uint jobNum=0)=0 |
virtual uint | getCurrentTextJob ()=0 |
virtual uint | getTextJobCount ()=0 |
virtual QString | getTextJobNumbers ()=0 |
virtual int | getTextJobState (const uint jobNum=0)=0 |
virtual QByteArray | getTextJobInfo (const uint jobNum=0)=0 |
virtual QString | talkerCodeToTalkerId (const QString &talkerCode)=0 |
virtual QString | getTextJobSentence (const uint jobNum=0, const uint seq=0)=0 |
virtual bool | isSpeakingText ()=0 |
virtual ASYNC | removeText (const uint jobNum=0)=0 |
virtual ASYNC | startText (const uint jobNum=0)=0 |
virtual ASYNC | stopText (const uint jobNum=0)=0 |
virtual ASYNC | pauseText (const uint jobNum=0)=0 |
virtual ASYNC | resumeText (const uint jobNum=0)=0 |
virtual QStringList | getTalkers ()=0 |
virtual ASYNC | changeTextTalker (const uint jobNum=0, const QString &talker=NULL)=0 |
virtual QString | userDefaultTalker ()=0 |
virtual ASYNC | moveTextLater (const uint jobNum=0)=0 |
virtual int | jumpToTextPart (const int partNum, const uint jobNum=0)=0 |
virtual uint | moveRelTextSentence (const int n, const uint jobNum=0)=0 |
virtual ASYNC | speakClipboard ()=0 |
virtual void | showDialog ()=0 |
virtual void | kttsdExit ()=0 |
virtual void | reinit ()=0 |
DCOP Signals | |
void | kttsdStarted () |
void | kttsdExiting () |
void | markerSeen (const QCString &appId, const QString &markerName) |
void | sentenceStarted (const QCString &appId, const uint jobNum, const uint seq) |
void | sentenceFinished (const QCString &appId, const uint jobNum, const uint seq) |
void | textSet (const QCString &appId, const uint jobNum) |
void | textAppended (const QCString &appId, const uint jobNum, const int partNum) |
void | textStarted (const QCString &appId, const uint jobNum) |
void | textFinished (const QCString &appId, const uint jobNum) |
void | textStopped (const QCString &appId, const uint jobNum) |
void | textPaused (const QCString &appId, const uint jobNum) |
void | textResumed (const QCString &appId, const uint jobNum) |
void | textRemoved (const QCString &appId, const uint jobNum) |
Public Attributes | |
k_dcop_signals | __pad0__: void ignoreThis() |
Detailed Description
kspeech - the KDE Text-to-Speech API.
- Version:
- 1.0 Draft 7
KTTSD -- the KDE Text-to-Speech Deamon -- is the program that supplies the services in the KDE Text-to-Speech API.
- Warning:
- The kspeech interface is still being developed and is likely to change in the future.
Features
- Priority system for Screen Readers, warnings and messages, while still playing regular texts.
- Long text is parsed into sentences. User may backup by sentence or part, replay, pause, and stop playing.
- Handles multiple speaking applications. Text messages are treated like print jobs. Jobs may be created, started, stopped, paused, resumed, and deleted.
- Speak contents of clipboard.
- Speak KDE notifications.
Requirements
KDE 3.2.x and a speech synthesis engine, such as Festival. Festival can be obtained from http://www.cstr.ed.ac.uk/projects/festival/. Festival is distributed with most Linux distros. Check your distro CDs. Also works with Festival Lite (flite), Hadifix (mbrola and txt2pho), FreeTTS, Epos, or any command that can speak text. Additional plugins are being developed.Design Goals
The KDE Text-to-Speech API is designed with the following goals:
- Support the features enumerated above.
- Plugin-based architecture for support of a wide variety of speech synthesis engines and drivers.
- Permit generation of speech from the command line (or via shell scripts) using the KDE DCOP utilities.
- Provide a lightweight and easily usable interface for applications to generate speech output.
- Applications need not be concerned about contention over the speech device.
- Provide limited support for speech markup languages, such as Sable, Java Speech Markup Language (JSML), and Speech Markup Meta-language (SMML). Basically, the goal is for KTTSD to permit pass-thru of markup to the speech engine. Generation and transformation of markup is left to higher layers or individual applications.
- Provide limited support for embedded speech markers.
- Asynchronous to prevent system blocking.
- Plugin-based audio architecture. Currently supports aRts but will support additional audio engines in the future, such as gstreamer.
- Compatible with original KTTSD API as developed by José Pablo Ezequiel "Pupeno" Fernández (avoid breaking existing applications).
Architecturally, applications interface with KTTSD, which performs queueing, speech job managment, plugin management and sentence parsing. KTTSD interfaces with a KTTSD speech plugin(s), which then interfaces with the speech engine(s) or driver(s).
application ^ | via DCOP (the KDE Text-to-Speech API) v kttsd ^ | KTTSD plugin API v kttsd plugin ^ | v speech engine
The KTTSD Plugin API is documented in PluginConf
There is a separate GUI application, called kttsmgr, for providing KTTSD configuration and job management.
kttsd maintains 4 types of speech output:
- Screen Reader Output
- Warnings
- Messages
- Text Jobs
Method sayScreenReaderOutput speaks Screen Reader output. It pre-empts any other speech in progress, including other Screen Reader outputs, i.e., it is not a queue. This method is reserved for use by Screen Readers.
Methods sayWarning and sayMessage place messages into the Warnings and Messages queues respectively. Warnings take priority over messages, which take priority over text jobs. Warnings and messages are spoken when the currently-speaking sentence of a text job is finished.
setText places text into the text job queue. startText begins speaking jobs. When one job finishes, the next job begins. Method appendText adds additional parts to a text job. Within a text job, the application (and user via the kttsmgr GUI), may back up or advance by sentence or part, or rewind to the beginning. See jumpToTextPart and moveRelTextSentence. Text jobs may be paused, stopped, and resumed or deleted from the queue. See pauseText, stopText, resumeText, and removeText.
DCOP Command-line Interface
To create a text job to be spoken
dcop kttsd kspeech setText <text> <talker>
where <text> is the text to be spoken, and <talker> is usually a language code such as "en", "cy", etc.
Example.
dcop kttsd kspeech setText "This is a test." "en"
To start speaking the text.
dcop kttsd kspeech startText 0
To stop speaking and rewind to the beginning of the text.
dcop kttsd kspeech stopText 0
Depending upon the speech plugin used, speaking may not immediately stop.
To stop and remove a text job.
dcop kttsd kspeech removeText 0
Note: For more information about talker codes, see Talkers, Talker Codes, and Plugins below.
Calling KTTSD from a Program
To make DCOP calls from your program, follow these steps:1. Include kspeech_stub.h in your code. Derive an object from the kspeech_stub interface. For example, suppose you are developing a KPart and want to call KTTSD. Your class declaration might look like this:
#include <kspeech_stub.h> class MyPart: public KParts::ReadOnlyPart, public kspeech_stub {
2. In your class constructor, initialize DCOPStub, giving it the sender "kttsd", object "kspeech".
MyPart::MyPart(QWidget *parent, const char *name) : KParts::ReadOnlyPart(parent, name), DCOPStub("kttsd", "kspeech") {
3. See if KTTSD is running, and if not, start it.
DCOPClient *client = dcopClient(); client->attach(); if (!client->isApplicationRegistered("kttsd")) { QString error; if (KApplication::startServiceByName("KTTSD", QStringList(), &error)) cout << "Starting KTTSD failed with message " << error << endl; }
4. Make calls to KTTSD in your code.
uint jobNum = setText("Hello World", "en"); startText(jobNum);
4. Add libktts to your Makefile.am.
mypart_la_LIBADD = libktts
Signals Emitted by KTTSD
KTTSD emits a number of DCOP signals, which provide information about sentences spoken, text jobs started, stopped, paused, resumed, finished, or deleted and markers seen. In general, these signals are broadcast to any application that connects to them. Applications should check the appId argument to determine whether the signal belongs to them or not.To receive KTTSD DCOP signals, follow these steps:
1. Include kspeechsink.h in your code. Derive an object from the KSpeechSink interface and declare a method for each signal you'd like to receive. For example, if you were coding a KPart and wanted to receive the KTTSD signal sentenceStarted:
#include <kspeechsink.h> class MyPart: public KParts::ReadOnlyPart, virtual public KSpeechSink { protected: ASYNC sentenceStarted(const QCString& appId, const uint jobNum, const uint seq);
You can combine sending and receiving in one object.
#include <kspeechsink.h> class MyPart: public KParts::ReadOnlyPart, public kspeech_stub, virtual public KSpeechSink { protected: ASYNC sentenceStarted(const QCString& appId, const uint jobNum, const uint seq);
See below for the signals you can declare.
2. In your class constructor, initialize DCOPObject with the name of your DCOP receiving object.
MyPart::MyPart(QWidget *parent, const char *name) : KParts::ReadOnlyPart(parent, name), DCOPObject("mypart_kspeechsink") {
Use any name you like.
3. Where appropriate (usually in your constructor), make sure your DCOPClient is registered and connect the KTTSD DCOP signals to your declared receiving methods.
// Register DCOP client. DCOPClient *client = kapp->dcopClient(); if (!client->isRegistered()) { client->attach(); client->registerAs(kapp->name()); } // Connect KTTSD DCOP signals to our slots. connectDCOPSignal("kttsd", "kspeech", "sentenceStarted(QCString,uint,uint)", "sentenceStarted(QCString,uint,uint)", false);
Notice that the argument signatures differ slightly from the actual declarations. For example
ASYNC sentenceStarted(const QCString& appId, const uint jobNum, const uint seq);
becomes
"sentenceStarted(QCString,uint,uint)",
in the connectDCOPSignal call.
4. Write the definition for the received signal. Be sure to check whether the signal is intended for your application.
ASYNC MyPart::sentenceStarted(const QCString& appId, const uint jobNum, const uint seq) { // Check appId to determine if this is our signal. if (appId != dcopClient()->appId()) return; // Do something here. }
5. Add libktts to your Makefile.am LIBADD variable:
libmypart_la_LIBADD = libktts
Talkers, Talker Codes, and Plugins
Many of the methods permit you to specify a desired "talker". This may be a simple language code, such as "en" for English, "es" for Spanish, etc. Code as NULL to use the default configured talker.Within KTTSMGR, the user has the ability to configure more than one talker for each language, with different voices, genders, volumes, and talking speeds.
Talker codes serve two functions:
- They identify configured plugins, and
- They provide a way for applications to specify the desired speaking attributes that influence the choice of plugin to speak text.
A Talker Code consists of a series of XML tags and attributes. An example of a full Talker Code with all attributes specified is
<voice lang="en" name="kal" gender="male"/> <prosody volume="soft" rate="fast"/> <kttsd synthesizer="Festival" />
(The voice and prosody tags are adapted from the W3C Speech Synthesis Markup Language (SSML) and Java Speech Markup Language (JSML). The kttsd tag is an extension to the SMML and JSML languages to support named synthesizers and text encodings.) KTTS doesn't really care about the voice, prosody, and kttsd tags. In fact, they may be omitted and just the attributes specified. The example above then becomes
lang="en" name="kal" gender="male" volume="soft" rate="fast" synthesizer="Festival"
The attributes may be specified in any order.
For clarity, the rest of the discussion will omit the voice, prosody, and kttsd tags.
The attributes that make up a talker code are:
- lang. Language code and optional country code. Examples: en, es, en_US, en_GB. Codes are case in-sensitive and hyphen (-) or underscore (_) may be used to separate the country code from the language code.
- synthesizer. The name of the synthesizer (plugin) used to produce the speech.
- gender. May be either "male", "female", or "neutral".
- name. The name of the voice code. The choice of voice codes is synthesizer-specific.
- volume. May be "loud", "medium", or "quiet". A synonym for "quiet" is "soft".
- rate. May be "fast", "medium", or "slow".
Each plugin, once it has been configured by a user in kttsmgr, returns a fully-specified talker code to identify itself. If the plugin supports it, the user may configure another instance of the plugin with a different set of attributes. This is the difference between a "plugin" and a "talker". A talker is a configured instance of a plugin. Each plugin (if it supports it) may be configured as multiple talkers.
When the user configures KTTSD, she configures one or more talkers and then places them in preferred order, top to bottom in kttsmgr. In effect, she specifies her preferences for each of the talkers.
When applications specify a talker code, they need not (and typically do not) give a full specification. An example of a talker code with only some of the attributes specified might be
lang="en" gender="female"
If the talker code is not in XML attribute format, it assumed to be a lang attribute. So the talker code
en
is interpreted as
lang="en"
When a program requests a talker code in calls to setText, appendText, sayMessage, sayWarning, and sayScreenReaderOutput, KTTSD tries to match the requested talker code to the closest matching configured talker.
The lang attribute has highest priority (attempting to speak English with a Spanish synthesizer would likely be unintelligible). So the language attribute is said to have "priority". If an application does not specify a language attribute, a default one will be assumed. The rest of the attributes are said to be "preferred". If KTTSD cannot find a talker with the exact preferred attributes requested, the closest matching talker will likely still be understandable.
An application may specify that one or more of the attributes it gives in a talker code have priority by preceeding each priority attribute with an asterisk. For example, the following talker code
lang="en" gender="*female" volume="soft"
means that the application wants to use a talker that supports American English language and Female gender. If there is more than one such talker, one that supports Soft volume would be preferred. Notice that a talker configured as English, Male, and Soft volume would not be picked as long as an English Female talker is available.
The algorithm used by KTTSD to find a matching talker is as follows:
- If language code is not specified by the application, assume default configured by user. The primary language code automatically has priority.
- (Note: This is not yet implemented.) If there are no talkers configured in the language, KTTSD will attempt to automatically configure one (see automatic configuraton discussion below)
- The talker that matches on the most priority attributes wins.
- If a tie, the one that matches on the most preferred attributes wins.
- If there is still a tie, the one nearest the top of the kttsmgr display (first configured) will be chosen.
This is best explained using examples. Suppose the user has configured the following talkers.
# lang synthesizer gender name volume rate - ---- ---------------- ------- ------ ------- ------- 1 en Festival Lite male Kal medium medium 2 en Festival Lite female Us1 soft medium 3 en Festival Int male Kal medium slow 4 de Hadifix male de1 medium medium
In this example, the user has specified that his default language code is en, He prefers to use the Festival Lite synthesizer. If not specified, text is assumed to be encoded using his desktop encoding. American Male (Kal) is the preferred gender and voice, and medium volume and rate are preferred. The numbers in the table above are to make the following discussion simpler.
Given the table above, a setText call with the following talker codes would use the indicated numbered talker for synthesis:
setText talker code plugin # explanation ------------------------------- -------- ------------------------- 0 (none) 1 None match, #1 is user preference. lang="en" 1 #1 thru #3 match, #1 is user preference. gender="male" 1 #1 and #3 match, #1 is user preference. #4 has the wrong language code. lang="de" 4 Single match on language. gender="female" 2 Single match on gender. synthesizer="Festival Int" 3 #2 and #3 partially match. gender="female" User preference order takes precedence. synthesizer="Festival Int" 2 #2 with two matches wins over #3 with gender="female" volume="soft" only one match. lang="es" synthesizer="Epos" 1 None of the talkers match at all. KTTSD attempted to configure a Spanish plugin but none were found. User preference chosen. gender="*female" 2 #2 is the only one that matches priority volume="medium" rate="slow" attribute gender="*male" rate="slow" 3 Three match priority attribute, but #3 also matches preferred attribute. name="de1" volume="medium" 1 Since language was not specified, it defaulted to en, thereby eliminating #4, and #1 is user preference. lang="cz" - KTTSD automatically loaded and configured the Epos plugin to speak Czech.
(Note: Not yet implemented). When picking a talker, KTTSD will automatically determine if text contains markup and pick a talker that supports that markup, if available. This overrides all other attributes, i.e, it is treated as an automatic "top priority" attribute.
Language codes actually consist of two parts, a language code and an optional country code. For example, en_GB is English (United Kingdom). The language code is treated as a priority attribute, but the country code (if specified) is treated as preferred. So for example, if an application requests the following talker code
lang="en_GB" gender="male" volume="medium"
then a talker configured as lang="en" gender="male" volume="medium" would be picked over one configured as lang="en_GB" gender="female" volume="soft", since the former matches on two preferred attributes and the latter only on the preferred attribute GB. An application can override this and make the country code priority with an asterisk. For example,
lang="*en_GB" gender="male" volume="medium"
To specify that American English is priority, put an asterisk in front of en_US, like this.
lang="*en_US" gender="male" volume="medium"
Here the application is indicating that a talker that speaks American English has priorty over one that speaks a different form of English.
(Note: Not yet implemented). If a language code is specified, and no plugin is currently configured with a matching language code, KTTSD will attempt to automatically load and configure a plugin to support the requested language. If there is no such plugin, or there is a plugin but it cannot automatically configure itself, KTTSD will pick one of the configured plugins using the algorithm given above.
Notice that KTTSD will always pick a talker, even if it is a terrible match. (The principle is that something heard is better than nothing at all. If it sounds terrible, user will change his configuration.) If an attribute is absolutely mandatory -- in other words the application must speak with the attribute or not at all -- the application can determine if there are any talkers configured with the attribute by calling getTalkers, and if there are none, display an error message to the user.
Applications can implement their own talker-matching algorithm by calling getTalkers, then finding the desired talker from the returned list. When the full talker code is passed in, KKTSD will find an exact match and use the specified talker. Applications can also determine what the user preferences are for attributes by calling userTalkerPreferences.
If an application requires a configuration that user has not created, it should display a message to user instructing them to run kttsmgr and configure the desired talker. (This must be done interactively because plugins often need user assistance locating voice files, etc.)
The above scheme is designed to balance the needs of applications against user preferences. Applications are given the control they might need, without unnecessarily burdening the application author. If you are an application author, the above discussion might seem overly complicated. It isn't really all that complicated. Here are rules of thumb:
- It is legitimate to give a NULL (0) talker code, in which case, the user's default talker will be used.
- If you know the language code, give that in the talker code, otherwise leave it out.
- If there is an attribute your application requires for proper functioning, specify that with an asterisk in front of it. For example, your app might speak in two different voices, Male and Female. (Since your app requires both genders, call getTalkers to determine if both genders are available, and if not, advise user to configure them. Better yet, give the user a choice of available distinquishing attributes (loud/soft, fast/slow, etc.)
- If there are other attributes you would prefer, specify those without an asterisk, but leave them out if it doesn't really make any difference to proper functioning of your application. Let the user decide them when they configure KTTS.
One final note about talkers. KTTSD does talker matching for each sentence spoken, just before the sentence is sent to a plugin for synthesis. Therefore, the user can change the effective talker in mid processing of a text job by changing his preferences, or even deleting or adding new talkers to the configuration.
Speech Markup
Note: Speech Markup is not yet implemented in KTTSD.Each of the five methods for queueing text to be spoken -- sayScreenReaderOutput, setText, appendText, sayMessage, and sayWarning -- may contain speech markup, provided that the plugin the user has configured supports that markup. The markup languages currently supported by plugins are:
- Sable 2.0: Festival
- Java Speech Markup Language (JSML): Festival (partial)
- Speech Synthesis Markup language (SSML): none at this time
TODO: Issue: Do Hadifix and FreeTTS support markup?
Before including markup in the text sent to kttsd, the application should query whether the currently-configured plugin supports the markup language by calling supportsMarkup.
Support for Markers
Note: Markers are not yet implemented in KTTSD.When using a speech markup language, such as Sable, JSML, or SSML, the application may embed named markers into the text. If the user's chosen speech plugin supports markers, KTTSD will emit DCOP signal markerSeen when the speech engine encounters the marker. Depending upon the speech engine and plugin, this may occur either when the speech engine encounters the marker during synthesis from text to speech, or when the speech is actually spoken on the audio device. The calling application can call the supportsMarkers method to determine if the currently configured plugin supports markers or not.
Sentence Parsing
Not all speech engines provide robust capabilities for stopping synthesis that is in progress. To compensate for this, KTTSD parses text jobs given to it by the setText and appendText methods into sentences and sends the sentences to the speech plugin one at a time. In this way, should the user wish to stop the speech output, they can do so, and the worst that will happen is that the last sentence will be completed.Sentence parsing also permits the user to rewind by sentences.
The default sentence delimiter used for plain text is as follows:
- A period (.), question mark (?), exclamation mark (!), colon (:), or semi-colon (;) followed by whitespace (including newline), or
- Two newlines in a row separated by optional whitespace.
When given text containing speech markup, KTTSD automatically determines the markup type and parses based on the sentence semantics of the markup language. TODO: ISSUE: Can this be reasonably done?
An application may change the sentence delimiter by calling setSentenceDelimiter prior to calling setText. Changing the delimeter does not affect other applications.
Text given to KTTSD via the sayWarning, sayMessage, and sayScreenReaderOutput methods is not parsed into sentences. For this reason, applications should not send long messages with these methods.
Authors
- Author:
- José Pablo Ezequiel "Pupeno" Fernández <pupeno@kde.org>
Gary Cramblitt <garycramblitt@comcast.net>
Olaf Schmidt <ojschmidt@kde.org>
Gunnar Schmi Dt <gunnar@schmi-dt.de>
Definition at line 651 of file kspeech.h.
Member Enumeration Documentation
|
Job states returned by method getTextJobState.
|
|
Speech markup language types.
|
Member Function Documentation
|
Determine whether the currently-configured speech plugin supports a speech markup language.
|
|
Determine whether the currently-configured speech plugin supports markers in speech markup.
|
|
Say a message as soon as possible, interrupting any other speech in progress. IMPORTANT: This method is reserved for use by Screen Readers and should not be used by any other applications.
|
|
Say a warning. The warning will be spoken when the current sentence stops speaking and takes precedence over Messages and regular text. Warnings should only be used for high-priority messages requiring immediate user attention, such as "WARNING. CPU is overheating."
|
|
Say a message. The message will be spoken when the current sentence stops speaking but after any warnings have been spoken. Messages should be used for one-shot messages that can't wait for normal text messages to stop speaking, such as "You have mail.".
|
|
Sets the GREP pattern that will be used as the sentence delimiter.
([\\.\\?\\!\\:\\;]\\s)|(\\n *\\n) Note that backward slashes must be escaped. When KTTSD parses the text, it replaces all tabs, spaces, and formfeeds with a single space, and then replaces the sentence delimiters using the following statement: temp.replace(sentenceDelimiter, "\\1\t"); which replaces all sentence delimiters with a tab, but preserving the first capture text (first parenthesis). In other words, the sentence punctuation is preserved. The tab is later used to separate the text into sentences. Changing the sentence delimiter does not affect other applications.
|
|
Queue a text job. Does not start speaking the text.
The text may contain speech mark language, such as Sable, JSML, or SSML, provided that the speech plugin/engine support it. In this case, sentence parsing follows the semantics of the markup language. Call startText to mark the job as speakable and if the job is the first speakable job in the queue, speaking will begin.
|
|
Adds another part to a text job. Does not start speaking the text.
|
|
Queue a text job from the contents of a file. Does not start speaking the text.
The text may contain speech mark language, such as Sable, JSML, or SSML, provided that the speech plugin/engine support it. In this case, sentence parsing follows the semantics of the markup language. Call startText to mark the job as speakable and if the job is the first speakable job in the queue, speaking will begin.
|
|
Get the number of sentences in a text job.
|
|
Get the job number of the current text job.
|
|
Get the number of jobs in the text job queue.
|
|
Get a comma-separated list of text job numbers in the queue.
|
|
Get the state of a text job.
|
|
Get information about a text job.
Note that sequence numbers apply to the entire job. They do not start from 1 at the beginning of each part. The following sample code will decode the stream: QByteArray jobInfo = getTextJobInfo(jobNum); QDataStream stream(jobInfo, IO_ReadOnly); int state; QCString appId; QString talker; int seq; int sentenceCount; int partNum; int partCount; stream >> state; stream >> appId; stream >> talker; stream >> seq; stream >> sentenceCount; stream >> partNum; stream >> partCount; |
|
Given a Talker Code, returns the Talker ID of the talker that would speak a text job with that Talker Code.
|
|
Return a sentence of a job.
|
|
Determine if kttsd is currently speaking any text jobs.
|
|
Remove a text job from the queue.
If there is another job in the text queue, and it is marked speakable, that job begins speaking. |
|
Start a text job at the beginning.
The job is marked speakable. If there are other speakable jobs preceeding this one in the queue, those jobs continue speaking and when finished, this job will begin speaking. If there are no other speakable jobs preceeding this one, it begins speaking. The textStarted signal is emitted when the text job begins speaking. When all the sentences of the job have been spoken, the job is marked for deletion from the text queue and the textFinished signal is emitted. |
|
Stop a text job and rewind to the beginning.
If there are speaking jobs preceeding this one in the queue, they continue speaking. If the job is currently speaking, the textStopped signal is emitted, the job stops speaking, and if the next job in the queue is speakable, it begins speaking. Depending upon the speech engine and plugin used, speeking may not stop immediately (it might finish the current sentence). |
|
Pause a text job.
If there are speaking jobs preceeding this one in the queue, they continue speaking. If the job is currently speaking, the textPaused signal is emitted and the job stops speaking. Note that if the next job in the queue is speakable, it does not start speaking as long as this job is paused. Depending upon the speech engine and plugin used, speeking may not stop immediately (it might finish the current sentence).
|
|
Start or resume a text job where it was paused.
If the job was not paused, it is the same as calling startText. If there are speaking jobs preceeding this one in the queue, those jobs continue speaking and when finished this job will begin speaking where it left off. The textResumed signal is emitted when the job resumes.
|
|
Get a list of the talkers configured in KTTS.
|
|
Change the talker for a text job.
|
|
Get the user's default talker.
|
|
Move a text job down in the queue so that it is spoken later.
|
|
Jump to the first sentence of a specified part of a text job.
|
|
Advance or rewind N sentences in a text job.
|
|
Add the clipboard contents to the text queue and begin speaking it.
|
|
Displays the KTTS Manager dialog. In this dialog, the user may backup or skip forward in any text job by sentence or part, rewind jobs, pause or resume jobs, or delete jobs. |
|
Stop the service.
|
|
Re-start KTTSD.
|
|
This signal is emitted when KTTSD starts or restarts after a call to reinit.
|
|
This signal is emitted just before KTTSD exits.
|
|
This signal is emitted when the speech engine/plugin encounters a marker in the text.
|
|
This signal is emitted whenever a sentence begins speaking.
|
|
This signal is emitted when a sentence has finished speaking.
|
|
This signal is emitted whenever a new text job is added to the queue.
|
|
This signal is emitted whenever a new part is appended to a text job.
|
|
This signal is emitted whenever speaking of a text job begins.
|
|
This signal is emitted whenever a text job is finished. The job has been marked for deletion from the queue and will be deleted when another job reaches the Finished state. (Only one job in the text queue may be in state Finished at one time.) If startText or resumeText is called before the job is deleted, it will remain in the queue for speaking.
|
|
This signal is emitted whenever a speaking text job stops speaking.
|
|
This signal is emitted whenever a speaking text job is paused.
|
|
This signal is emitted when a text job, that was previously paused, resumes speaking.
|
|
This signal is emitted whenever a text job is deleted from the queue. The job is no longer in the queue when this signal is emitted.
|
The documentation for this class was generated from the following file: