[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Writing a driver for Finnish speaking synthesizer?

From: Petteri Heiskari
Subject: Writing a driver for Finnish speaking synthesizer?
Date: Mon, 24 Nov 2008 14:53:36 +0200

Thanks Hynek!

I was able to do the old fashion Speech Dispatcher interface to our speech
synthesizer and it is now being tested by Finnish Federation of Visually
Impaired people.

The way you told the synchronization works sounds simple and therefore
perfect. I attached the interface code I have used if it could be useful for
someone. However it depends on many other globals etc so it cannot be used
elsewhere without many changes. And it has Finnish comments also to make it
harder to read :)

Best regards, Petteri

-----Original Message-----
From: Hynek Hanke [mailto:address@hidden 
To: address@hidden
Sent: 25 October 2008 13:28
To: Petteri Heiskari
Cc: speechd at lists.freebsoft.org
Subject: Re: Writing a driver for Finnish speaking synthesizer?

Petteri Heiskari wrote:
> I noticed one "specification bug" in Speech Dispatcher docs. It states 
> that output module may not send notification replies like 701 EVENT 
> BEGIN when processing for example SPEAK-command.
> However the output module cannot lock any mutex at right time. The 
> exact time should be _before_ Speech Dispatcher starts to send 
> command, for example line:
> Since Speech Dispatcher and output modules are separate processes, 
> there is no simple way to synhronize this I guess.

Actually, there is. I don't think there is any problem, just that the
documentation is not so clear about it. Before Speech Dispatcher sends any
new requests (like SET, SPEAK etc.) it waits for the previous request to be
terminated by the output module by signalling "STOP", "END" or "PAUSE" index
marks. So there can't possibly be any pending index marks when Speech
Dispatcher sends the "SPEAK" command.

The only thing the output module must ensure is that it doesn't send any
index marks until it acknowledges the receival of the new message via ,,200
OK SPEAKING''. It must also ensure that index marks written to the pipe are
well ordered -- of course it doesn't make any sense to send any index marks
after "STOP", "END" or "PAUSE" is sent.

I've modified the documentation a bit and I hope it is now clear about this

The method you suggested of handling index marks really asynchronously is
what I now consider a better solution as it is more bullet proof and easier
to debug if one of the two sides doesn't do their job well. Also, it allows
for a better flexibility of the communication protocol. We have implemented
this method in the TTS API Provider I told you about and this is also why I
was a little confused by your question at first. Please apologize my late

With regards,
Hynek Hanke

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mplinux_sd.cpp

reply via email to

[Prev in Thread] Current Thread [Next in Thread]