Rockbox

I think its great sapi is being worked on,
However just a few thoughts, is this application going to remain command line? or will it get a gui interface?
Personally I would prefer gui.
Also, why have you only attached a compiled executable to the task? why not attach your code as well, that way other people can work on this as well if they want to.

Point taken the code is current in SVN here:

http://code.google.com/p/open-sapi/source/browse/#svn/trunk/open-sapi/rockbox

Good luck with tcl, it is not too bad to read. ;)

I have tested this with the rbutility in Linux using wine and it runs, but very slowly due to firing up wine each time you make a call to generate speech.

So i am making a server / client where the server stays running and the client runs each time removing the wine startup delay.
This isn't a problem in Windows but this is beng designed .

continues….. with more than just windows users in mind.

The server will be compiled as an exe file but the client will be compiled for the specific target system / or run as a script running natively communicating over sockets.

There is also my patch for getting rbutility to have an entry in the TTS engines list.

Tom

   tts.cpp -sapi-spk.patch (0 KiB)

Try saving the file first :S

   tts.cpp -sapi-spk.patch (0.9 KiB)

Note: Next time when saving your patch, don't put a "space". Use "_" or "-" Because with the space it reads, "tts.cpp" not "tts.cpp -sapi-spk.patch" Just to let you know ;)

This release is a Linux/Wine build that can not be used under windows.

There has been a total rework for increased performance and integration into rbutil.

We now have a Server and Client that communicates using sockets, this has potential to be integrated directly into rbutil and not need a stand alone client in the future.

Certain features are hardcoded at the moment for testing purposes like communicating over port 5491.

To create a system capable of running this code please download and run these commands (debian). This should run under other distributions. Please modify as appropriate.

sudo apt-get install wine

wget http://open-sapi.googlecode.com/files/wineinit.exe wine wineinit.exe

wget http://open-sapi.googlecode.com/files/winetricks.sh chmod 770 winetricks.sh
./winetricks.sh sapi51

wget http://open-sapi.googlecode.com/files/msvcp60.dll cp -f msvcp60.dll $HOME/.wine/drive_c/windows/system32/

That completes the system setup, you then need to download the server and client from here and run the server in a terminal preferably with a -v option to get debug output.

The original patch supplied above will get you the option in rbuntil to choose the client as tts engine executable. Again add a -v option to get verbose output. You must recompile rbutil before this will take effect.

At the moment certain directories are failing in rbutil, changing if you do the whole lot at once to the specific directory can fix it, specifying files only or directory only and also to include extensions also has an effect. Which at present is unexplained but that's why i am uploading the work so far.

Tom

   client.linux.tar.gz (1.41 MiB)
   server.exe (765.7 KiB)

I just tried this and it seems to work in prinziple
For better use it could use some improvements.

It also fails for me at encoding one file. The cause for this is that rbutil request two files which only differ in casing.
Example: /tmp/shf.wav and /tmp/Shf.wav (note the big S)
And your tts engine always generates filenames with only lower casing, thats why encoding later misses one file, and stops.

Through further investigations i have found that as wine emulates our friendly windows OS we have case insensitive file manipulation going on in a case sensitive environment.

So our rbutil looks for case sensitive filenames and will fail as wine / tcl just renames the same filename with the last case change even when i force a filename change or copy. Great :( . This may need a little bit of work on rbutil to make the filename checking to be case insensitive when it is looking for files to copy to a new locations (in linux) , then renaming them to be consisten with their real names from the file system. I imagine this already happens under the windows code but i may be mistaken.

I have also included a directory structure that is failing for testing if and when people get the chance.

Please note that the dirname is "Rouge Element - Rouge Rock" rbutil is looking for and generates "Rouge Element - Rouge rock" removing the "-" in the past made a difference, but i have not rechecked it yet.

Tom

   Rogue Element - Rogue Rock.ta... (0.5 KiB)

It has been suggested that the tolower command is used in QT on all the filenames and then a compare is done when the copy process it done to verify the name before moving and changing the case back to the original, I can see you are keeping ltables of the orginal filenames already so that will be very useful to implement these changes. This means that you only need one file for multiple entries which are the same name but not case which i guess is what happens under windows but not Linux at this time.

As i see the code working the filenames which are the same are still generated even though they already exist (linux & wine combo) I am not sure if there is a check to see if the file needs to be generated somewhere and then it is skipped? This can be done in my server with no trouble but might be beneficial to do it in rbutil as it means it filters down to all the tts engines. This will also have some very small but still improvements in the efficiency when generating large amount of dirs and filenames which are the same.

I am suggesting this change to help integrate this so that users can use it in Linux and Windows the same, in theory there should not be this issue on windows. Let me know what you think.

Tom

I just checked the directory you provided. And it also contains two names which only differ in casing.
Directory name: "Rogue Element - Rogue Rock" and the File "Rogue Element - Rogue rock.m3u". If you remove the file extension, they result into the same name with different Casing.
This also explains why it would work if you voice Dirs and files seperately.

I am still not sure what the real fix for this would be. I would think the TTS engine might speak different depending on casing. So if we want to preserve that, we should maybe use something like a md5sum of the spoken texts as intermediate filename in rbutil.

Not generating the same text twize in rbutil might be a good improvement for speed, but i am unsure if its worth the more complicated handling.

I made a minimal client built into rbutil.
So far it works to generate, but no settings are exported.

What needs to improved in the Server is:
- output of all get Commands send to the client.
- the speakMe message needs some answer, so the client knows when generation is finished.

   rbutil-opensapiclient.patch (4.3 KiB)

I now tried the Idea of using md5sum of the spoken text as intermediate Filenames for .talk file generation.
It seems to work fine. But it also shows that the talkfile (and voicefile) generation could be improved

So this patch contains:
- md5sums as intermediate filenames → solves the broken encoding bug.
- minimal client for open-sapi.
- old code for the open-sapi cli client

   rbutil-opensapiclient-v2.patch (7.4 KiB)

updated patch to svn.

Also i tried it on windows. I can start the server, and it also shows when the client tries to connect. But somehow the "waitForConnected()" call in Qt times out.

   rbutil-opensapiclient-v3.patch (3.1 KiB)

Now i added many configuration options, and a try at starting the server from rbutil.

Edit:
The starting of the server doesnt work, will have to find out how to start a wine programm out of a native one.
And the sending of voice messages is somehow broken again. The Server complains about the message.

   rbutil-opensapiclient-v4.patch (7.8 KiB)

small fixes. It still has some problems and starting the server is currently commented.

   rbutil-opensapiclient-v5.patch (8.9 KiB)

Now starting of the wine executeable from rbutil is working.
It could still need some improvements.. but it works

Unfortunatly it seem QSound::play(..) doesnt seem to work in my Linux.

   rbutil-opensapiclient-v6.patch (9.9 KiB)

Right here we have a few nights worth of work. It is not perfection yet as the verbose output is still a little rough around the edges. As far as i have tested client to server communication is okay and does what is says on the tin.

See notes for development here: (These pages are being updated so I will post here when i have them 100% accurate as some development have happened since these pages were last modified)

http://code.google.com/p/open-sapi/wiki/RockboxUtility

Shortly to follow will be the modifications to the configure script that will help generate the voice file for unsupported platforms that are still under development.

Tom

   rbutil-sapi-server.exe (777.2 KiB)
   rbutil-sapi-cli.exe (660.8 KiB)
   rbutil-sapi-cli-linux.tar.gz (1.41 MiB)

Right the specs on the wiki are finalised now

This patch contains the first attempt at using this in rbutil.

What is still left todo:
- Better handling of the answers from the server.
- Configure options for the wavformat.
- Better error handling.

And only tested on windows

   rbutil-opensapi.patch (16.6 KiB)

Additions made:

202 :Setting OK:command called

This is returned after each setting change made on the server.

293:End of List:

This is returned after the last entry in the lists from getEngine and getFprmat

Fixes added for setPitch, timeouts not registering.

   rbutil-sapi-cli.exe (660.8 KiB)
   rbutil-sapi-server.exe (777.3 KiB)
   rbutil-sapi-cli-linux.tar.gz (1.41 MiB)

new patch adapted to the changes in the server.
It now also adds the wavformat list to the settings.

Still only tested on windows, but works fine there.

There is probably some more work needed for better error handling, and info for user on linux/mac

   rbutil-opensapi2.patch (19.1 KiB)

New patch.

this should now also work on linux.

   rbutil-opensapi3.patch (20.1 KiB)

After a fresh svn update of rbutil and a patch i am still getting error:

make[1]: * No rule to make target `rbutilqt-sapi.qrc', needed by `build/rcc/qrc_rbutilqt-sapi.cpp'. Stop.
make[1]: Leaving directory `/home/tom/rockbox/rbutil/rbutilqt'
make: * [sub-rbutilqt-make_default] Error 2

The patch is failing:

1 out of 1 hunk ignored
(Stripping trailing CRs from patch.)
patching file rbutilqt-sapi.qrc
(Stripping trailing CRs from patch.)
can't find file to patch at input line 639

Had to manually create and add the contents for the missing file. now sure why maybe i am running patch the wrong way but it now compiles and runs.

I have notived that the format list when shown is missing the last entry on the list.

Rbutil is sometimes not able to connect to the opensapi-server. I am not sure but this might be todo with the way that sometimes the server is shutdown? It is important to do this and to not just close the server without closing the client making sure the sockets are closed properly.

On file generation the log gets information about the synthesis even when there are no errors to report

When the option to overwrite existing .talk files is not ticked the process fails. If it is ticked it works fine.

Update the patch to the changes in SVN.
No other changes.

   rbutil-opensapi4.patch (23 KiB)

Another release

Notes on the new return codes can be found here:

http://code.google.com/p/open-sapi/wiki/RockboxUtilityCommsSpec?ts=1275767485&updated=RockboxUtilityCommsSpec

Issues that needed to be addressed were:
The formats list was one entry too short.
The server start-up and shut-down was unreliable.
The client should use the close client return code as a signal to continue rather than time outs currently used.
Settings can be stored in rbutil and do not have to be read from the server each time. (Depending if the user moves from computer to computer with rbutil on the player if the voice list is the same)

Thanks,

NL

   rbutil-sapi-server.exe (781.8 KiB)

Revised version with getFormat fix

   rbutil-sapi-server.exe (781.8 KiB)

New patch to use the open-sapi server in rbutil.
Server gets downloaded on demand.

actual voice generation doesnt work…

   rbutil-opensapi5.patch (23.3 KiB)

Right been bug hunting a bit this evening:

Sorted out a few bugs in various places making the server code stable as far as I can test at the moment when working with rbutil.

I changed the patch above to include the code that sets outfile on a separate line as that was still commented on the last patch.

That makes it work better. I also fixed and issue with how sockets are closed and when.

Lastly I found a missing debug statement also fixed.

A new release has been uploaded to google and the version number increased by one.

The last error is on your side with the way killServer is called. This should only be called when you want the server to close and do no more work. At the moment the killServer commands being called after each wav generation. which means the server is no longer there for rbutil to talk to. The desired use of killServer is when you are finished with TTS generation. You might not be happy to but you could start and leave the server running when rbutil starts and then close it on exit. This will mean that start up times are minimised. The server uses very few resources when it is idle.

See what you think.

NL

Oh also the wav format list does not show in the list box when changing the settings.

Further testing has seen that the server is not returning the list of formats quickly enough and rbutil is not waiting for the last list element which is a 293 return code. The server returns this when there is no more data. There should be a very large time-out on this command as it is slow. I am not sure of a way to speed it up yet.

The user might like some meaningful feedback, a progress bar that says what it is doing so getting voices, rate, speed, fomat list etc etc. At the moment it is little bit like what's happening. Just so you know it is doing something.

Seems that after the server is run internally from within Rbutil when you want to change the setting that the server is left running in the background. This might be what you wanted to do but I just wanted to make you aware that is is not closing. When i run the server externally it is issued with a killServer command at the end of the config process. This is not honoured by the internally run server.

This can be demonstrated by running the config close and then running it again. You are presented by a blank dialogue box. This I am sure is saying unable to start server.

What I think needs to happen is:
Rbutil sends a killServer Command to the server
The server sends you a 299 response to say it will shutdown. When the client receives this notification the client should then close its socket connection. This then stops the server socket being blocked by a problem that if there are client sockets still open on that socket even after the server closes then that address will be locked for anywhere up to 30 seconds stopping the server running again using the socket address.

This should sort out the problem that you can not restart the server on the same port straight after.

I just tried it on windows, and there it works fine.

Regarding your findings:
- rbutil should not call killServer after every .wav generation, the code only does that when its finsihed with voicing. (unless there is a big bug somewhere)
- The format list will be missing if we run into that 5 second timeout.. perhaps i have to improve the timeout handling somewhat for that.
- More meaningfull feedback is difficult, because the UI is generic to all TTS engines. All you get currently is a running progressbar
- rbutil should start and stop the server when you open the config screen..if not, there is a bug (also unlikely as other TTS engines work fine).
- The empty config dialog is surely a sign that the starting of the server failed.. i would need to reproduce or get a System Trace to find out whats going wrong there.
- After Opensapi gets the killServer command, i close the socket, and kill the process if it is still running… so that shouldnt happen..

The issue is not so prevalent in windows because wine is slowing the whole process at the moment. What is happening is a potential issue on a slower windows box too.

I think what is happening is your calling speakMe
The server returns a 201 - synthOK - but it has not really finished all the work yet
Then the server returns a 294 - closeClient which is when the server has really finished all the process and is ready for the next job.

So each TalkGen must finish with a closeClient command not a 201 - synthOk that way everything is kept in sync.

Looking at the logs it seems that rbutil is calling another speech gen request before the server has finished the last one, which is probably screwing up the file generation.
That is probaly bad coding my end but also your end not following to spec, well not that I have put that in the spec but you know what i mean.

TalkGen] voicing: "Chase and Status & VC - The Grudge" to "/tmp/talkfiles/2601e5bc3ca57b017005c50e707f2941.wav"
[Opensapi] cmd: "outFile /tmp/talkfiles/2601e5bc3ca57b017005c50e707f2941.wav"
[Opensapi] answer: "202:Setting OK:outFile
"
[Opensapi] cmd: "speakMe Chase and Status & VC - The Grudge"
[Opensapi] answer: "201:Synth OK:
294:Close Client:
"
[TalkGen] voicing: "aa-chase_and_status-judgement_(informer)-sour" to "/tmp/talkfiles/89ba30fdfafb8f8fa8b9f6f6b7321478.wav"
[Opensapi] cmd: "outFile /tmp/talkfiles/89ba30fdfafb8f8fa8b9f6f6b7321478.wav"
[Opensapi] answer: "202:Setting OK:outFile
"
[Opensapi] cmd: "speakMe aa-chase_and_status-judgement_(informer)-sour"
[Opensapi] answer: "201:Synth OK:
"
[TalkGen] voicing: "a-chase_and_status-the_druids" to "/tmp/talkfiles/5eaa33e7dc41e3558da00a57dbf43e0e.wav"
[Opensapi] cmd: "outFile /tmp/talkfiles/5eaa33e7dc41e3558da00a57dbf43e0e.wav"
* This close should be three lines up from the previous syth command but we are already on another request. * [Opensapi] answer: "294:Close Client:
"
[Opensapi] cmd: "killServer"
[Opensapi] answer: "201:Synth OK:
"
[Opensapi] unable to stop server "201:Synth OK:
"
[Opensapi] old data detected: "294:Close Client:
202:Setting OK:outFile
299:Shutdown OK:
"

Futher log analysis shown from the server that::

First time around we set the outfile from rbutil fine
File 1
Jun 08 23:09:03 socketMsgIn: sock276:Message : outFile /tmp/talkfiles/1e7f44fd8e4b4fa4470104724ca15f78.wav
Jun 08 23:09:03 socketMsgIn: outFile from sock276
Jun 08 23:09:03 varSetting: filename set: /tmp/talkfiles/1e7f44fd8e4b4fa4470104724ca15f78.wav
Jun 08 23:09:03 socketMsgOut: 202:Setting OK:Filename Set - /tmp/talkfiles/1e7f44fd8e4b4fa4470104724ca15f78.wav
Jun 08 23:09:03 programFlow: proc bugClient {202 outFile sock276}
Jun 08 23:09:04 programFlow: idleServerTimeout {60000}
Jun 08 23:09:04 programFlow: proc serverRead {sock276 ::tcom::handle0x00D03CB8}
Jun 08 23:09:04 socketMsgIn: sock276:Message : speakMe RES_INFO.SYS
Jun 08 23:09:04 socketMsgIn: speakMe from sock276
Jun 08 23:09:04 generalInfo: speakMe : RES_INFO.SYS
Jun 08 23:09:04 programFlow: proc genfiles {::tcom::handle0x00D03CB8 /tmp/talkfiles/16cbba237427959b3c49956a66af117d.wav <pitch absmiddle="10"/> RES_INFO.SYS 22}

Second time around again outfile is set
File 2
Jun 08 23:09:04 socketMsgIn: outFile from sock276
Jun 08 23:09:04 varSetting: filename set: /tmp/talkfiles/16cbba237427959b3c49956a66af117d.wav
Jun 08 23:09:04 socketMsgOut: 202:Setting OK:Filename Set - /tmp/talkfiles/16cbba237427959b3c49956a66af117d.wav
Jun 08 23:09:04 programFlow: proc bugClient {202 outFile sock276}
Jun 08 23:09:03 programFlow: idleServerTimeout {60000}
Jun 08 23:09:03 programFlow: proc serverRead {sock276 ::tcom::handle0x00D03CB8}
Jun 08 23:09:03 socketMsgIn: sock276:Message : outFile /tmp/talkfiles/1e7f44fd8e4b4fa4470104724ca15f78.wav
Jun 08 23:09:03 socketMsgIn: outFile from sock276
Jun 08 23:09:03 varSetting: filename set: /tmp/talkfiles/1e7f44fd8e4b4fa4470104724ca15f78.wav
Jun 08 23:09:03 socketMsgOut: 202:Setting OK:Filename Set - /tmp/talkfiles/1e7f44fd8e4b4fa4470104724ca15f78.wav
Jun 08 23:09:03 programFlow: proc bugClient {202 outFile sock276}
Jun 08 23:09:03 programFlow: idleServerTimeout {60000}
Jun 08 23:09:03 programFlow: proc serverRead {sock276 ::tcom::handle0x00D03CB8}
Jun 08 23:09:03 socketMsgIn: sock276:Message : speakMe SYS_CONF.SYS
Jun 08 23:09:03 socketMsgIn: speakMe from sock276
Jun 08 23:09:03 generalInfo: speakMe : SYS_CONF.SYS
Jun 08 23:09:03 programFlow: proc genfiles {::tcom::handle0x00D03CB8 /tmp/talkfiles/1e7f44fd8e4b4fa4470104724ca15f78.wav <pitch absmiddle="10"/> SYS_CONF.SYS 22}

Third time for some reason the outfile is not set not even send.
File 3
*** We are missing an outfile setting here so the server is using the same file name details as before overwriting the previous file ^^ from above rbutil is looking for the file it wants and not getting it.
There is no file name being sent to the server or it is being lost somewhere along the way I do not know? The debug information shows any messages correct or not that come into the socket connection.
Jun 08 23:09:05 programFlow: idleServerTimeout {60000}
Jun 08 23:09:05 programFlow: proc serverRead {sock276 ::tcom::handle0x00D03CB8}
Jun 08 23:09:05 socketMsgIn: sock276:Message : speakMe RES_INFO.SYS
Jun 08 23:09:05 socketMsgIn: speakMe from sock276
Jun 08 23:09:05 generalInfo: speakMe : RES_INFO.SYS
Jun 08 23:09:05 programFlow: proc genfiles {::tcom::handle0x00D03CB8 /tmp/talkfiles/16cbba237427959b3c49956a66af117d.wav <pitch absmiddle="10"/> RES_INFO.SYS 22}

File 4
23:09:06 programFlow: idleServerTimeout {60000}
Jun 08 23:09:06 programFlow: proc serverRead {sock276 ::tcom::handle0x00D03CB8}
Jun 08 23:09:06 socketMsgIn: sock276:Message : outFile /tmp/talkfiles/079c5419c88fb559a3f74629f6f7eb38.wav
Jun 08 23:09:06 socketMsgIn: outFile from sock276
Jun 08 23:09:06 varSetting: filename set: /tmp/talkfiles/079c5419c88fb559a3f74629f6f7eb38.wav
Jun 08 23:09:06 socketMsgOut: 202:Setting OK:Filename Set - /tmp/talkfiles/079c5419c88fb559a3f74629f6f7eb38.wav
Jun 08 23:09:06 programFlow: proc bugClient {202 outFile sock276}
Jun 08 23:09:06 programFlow: idleServerTimeout {60000}
Jun 08 23:09:06 programFlow: proc serverRead {sock276 ::tcom::handle0x00D03CB8}

Here rbtuil is unhappy about the duplicate files that have overwritten above and decides to call it a day closing us down for not doing the job properly.
Jun 08 23:09:06 socketMsgIn: sock276:Message : killServer
Jun 08 23:09:06 socketMsgIn: killServer from sock276
Jun 08 23:09:06 programFlow: proc closeMe {client sock276}
Jun 08 23:09:06 programFlow: proc bugClient {299 sock276}
Jun 08 23:09:06 generalInfo: Cleaning Up…………..OK

Again looking closely I can see that the middle request is called twice to voice the same files, there is no outfile set though.
I can see that because there is no outfile set rbutil sees this an an error and exits. Hence the error message given to the user:

Voicing of aa-chase_and_status-judgement_(informer)-sour failed: Could not set outputfile. pasted from rbutil.

Open Sapi Server output:

programFlow: proc serverRead {sock276 ::tcom::handle0x00D03CB8}
Jun 09 00:03:12 socketMsgIn: sock276:Message : outFile /tmp/talkfiles/2601e5bc3ca57b017005c50e707f2941.wav
Jun 09 00:03:12 socketMsgIn: outFile from sock276
Jun 09 00:03:12 varSetting: filename set: /tmp/talkfiles/2601e5bc3ca57b017005c50e707f2941.wav
Jun 09 00:03:12 socketMsgOut: 202:Setting OK:Filename Set - /tmp/talkfiles/2601e5bc3ca57b017005c50e707f2941.wav
Jun 09 00:03:12 programFlow: proc bugClient {202 outFile sock276}
Jun 09 00:03:12 programFlow: idleServerTimeout {60000}
Jun 09 00:03:13 programFlow: proc serverRead {sock276 ::tcom::handle0x00D03CB8}
Jun 09 00:03:13 socketMsgIn: sock276:Message : speakMe Chase and Status & VC - The Grudge
Jun 09 00:03:13 socketMsgIn: speakMe from sock276
Jun 09 00:03:13 generalInfo: speakMe : Chase and Status & VC - The Grudge
Jun 09 00:03:13 programFlow: proc genfiles {::tcom::handle0x00D03CB8 /tmp/talkfiles/2601e5bc3ca57b017005c50e707f2941.wav <pitch absmiddle="10"/> Chase and Status & VC - The Grudge 22}
Jun 09 00:03:13 programFlow: proc extCmdExeErrWrapper {::tcom::ref createobject Sapi.SpFileStream}
Jun 09 00:03:13 programFlow: proc extCmdExeErrWrapper {::tcom::ref createobject Sapi.SpAudioFormat}
Jun 09 00:03:13 programFlow: proc extCmdExeErrWrapper {file mkdir {C:\users\tom/sapiTMP}}
Jun 09 00:03:13 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D7AF68 Type 22}
Jun 09 00:03:13 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D79EB8 Format ::tcom::handle0x00D7AF68}
Jun 09 00:03:13 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D79EB8 Open {C:\users\tom/sapiTMP/opensapitmp.wav} 3 False}
Jun 09 00:03:13 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D03CB8 AudioOutputStream ::tcom::handle0x00D79EB8}
Jun 09 00:03:14 generalInfo: Synthesising : <pitch absmiddle="10"/> Chase and Status & VC - The Grudge
Jun 09 00:03:14 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D03CB8 Speak {<pitch absmiddle="10"/> Chase and Status & VC - The Grudge} 0}
Jun 09 00:03:15 programFlow: proc cleanUp {/tmp/talkfiles/2601e5bc3ca57b017005c50e707f2941.wav ::tcom::handle0x00D79EB8}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D79EB8 Close}
Jun 09 00:03:15 programFlow: proc bugClient {201 sock276}
Jun 09 00:03:15 socketMsgOut: 201:Synth OK : genText

Jun 09 00:03:15 programFlow: idleServerTimeout {60000}
Jun 09 00:03:15 programFlow: proc serverRead {sock276 ::tcom::handle0x00D03CB8}
Jun 09 00:03:15 socketMsgIn: sock276:Message : outFile /tmp/talkfiles/89ba30fdfafb8f8fa8b9f6f6b7321478.wav
Jun 09 00:03:15 socketMsgIn: outFile from sock276
Jun 09 00:03:15 varSetting: filename set: /tmp/talkfiles/89ba30fdfafb8f8fa8b9f6f6b7321478.wav
Jun 09 00:03:15 socketMsgOut: 202:Setting OK:Filename Set - /tmp/talkfiles/89ba30fdfafb8f8fa8b9f6f6b7321478.wav
Jun 09 00:03:15 programFlow: proc bugClient {202 outFile sock276}
Jun 09 00:03:15 programFlow: idleServerTimeout {60000}
Jun 09 00:03:15 programFlow: proc serverRead {sock276 ::tcom::handle0x00D03CB8}
Jun 09 00:03:15 socketMsgIn: sock276:Message : speakMe aa-chase_and_status-judgement_(informer)-sour
Jun 09 00:03:15 socketMsgIn: speakMe from sock276
Jun 09 00:03:15 generalInfo: speakMe : aa-chase_and_status-judgement_(informer)-sour
Jun 09 00:03:15 programFlow: proc genfiles {::tcom::handle0x00D03CB8 /tmp/talkfiles/89ba30fdfafb8f8fa8b9f6f6b7321478.wav <pitch absmiddle="10"/> aa-chase_and_status-judgement_(informer)-sour 22}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::ref createobject Sapi.SpFileStream}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::ref createobject Sapi.SpAudioFormat}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D71020 Type 22}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D71580 Format ::tcom::handle0x00D71020}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D71580 Open {C:\users\tom/sapiTMP/opensapitmp.wav} 3 False}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D03CB8 AudioOutputStream ::tcom::handle0x00D71580}
Jun 09 00:03:15 generalInfo: Synthesising : <pitch absmiddle="10"/> aa-chase_and_status-judgement_(informer)-sour
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D03CB8 Speak {<pitch absmiddle="10"/> aa-chase_and_status-judgement_(informer)-sour} 0}
Jun 09 00:03:15 programFlow: proc cleanUp {/tmp/talkfiles/89ba30fdfafb8f8fa8b9f6f6b7321478.wav ::tcom::handle0x00D71580}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D71580 Close}
Jun 09 00:03:15 programFlow: proc bugClient {201 sock276}
Jun 09 00:03:15 socketMsgOut: 201:Synth OK : genText

This seems to be a repeat of the previous request again without the outfile definition? Is this throwing things out of sync?
As far as open-sapi is concerned this request is okay but just not efficient.

Jun 09 00:03:15 programFlow: idleServerTimeout {60000}
Jun 09 00:03:15 programFlow: proc serverRead {sock276 ::tcom::handle0x00D03CB8}
Jun 09 00:03:15 socketMsgIn: sock276:Message : speakMe aa-chase_and_status-judgement_(informer)-sour
Jun 09 00:03:15 socketMsgIn: speakMe from sock276
Jun 09 00:03:15 generalInfo: speakMe : aa-chase_and_status-judgement_(informer)-sour
Jun 09 00:03:15 programFlow: proc genfiles {::tcom::handle0x00D03CB8 /tmp/talkfiles/89ba30fdfafb8f8fa8b9f6f6b7321478.wav <pitch absmiddle="10"/> aa-chase_and_status-judgement_(informer)-sour 22}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::ref createobject Sapi.SpFileStream}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::ref createobject Sapi.SpAudioFormat}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D7BFE0 Type 22}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D79EB8 Format ::tcom::handle0x00D7BFE0}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D79EB8 Open {C:\users\tom/sapiTMP/opensapitmp.wav} 3 False}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D03CB8 AudioOutputStream ::tcom::handle0x00D79EB8}
Jun 09 00:03:15 generalInfo: Synthesising : <pitch absmiddle="10"/> aa-chase_and_status-judgement_(informer)-sour
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D03CB8 Speak {<pitch absmiddle="10"/> aa-chase_and_status-judgement_(informer)-sour} 0}
Jun 09 00:03:15 programFlow: proc cleanUp {/tmp/talkfiles/89ba30fdfafb8f8fa8b9f6f6b7321478.wav ::tcom::handle0x00D79EB8}
Jun 09 00:03:15 programFlow: proc extCmdExeErrWrapper {::tcom::handle0x00D79EB8 Close}
Jun 09 00:03:16 programFlow: proc bugClient {201 sock276}
Jun 09 00:03:16 socketMsgOut: 201:Synth OK : genText

Jun 09 00:03:16 programFlow: idleServerTimeout {60000}
Jun 09 00:03:16 programFlow: proc serverRead {sock276 ::tcom::handle0x00D03CB8}
Jun 09 00:03:16 socketMsgIn: sock276:Message : outFile /tmp/talkfiles/5eaa33e7dc41e3558da00a57dbf43e0e.wav
Jun 09 00:03:16 socketMsgIn: outFile from sock276
Jun 09 00:03:16 varSetting: filename set: /tmp/talkfiles/5eaa33e7dc41e3558da00a57dbf43e0e.wav
Jun 09 00:03:16 socketMsgOut: 202:Setting OK:Filename Set - /tmp/talkfiles/5eaa33e7dc41e3558da00a57dbf43e0e.wav
Jun 09 00:03:16 programFlow: proc bugClient {202 outFile sock276}
Jun 09 00:03:16 programFlow: idleServerTimeout {60000}
Jun 09 00:03:16 programFlow: proc serverRead {sock276 ::tcom::handle0x00D03CB8}
Jun 09 00:03:16 socketMsgIn: sock276:Message : killServer
Jun 09 00:03:16 socketMsgIn: killServer from sock276
Jun 09 00:03:16 programFlow: proc closeMe {client sock276}
Jun 09 00:03:16 programFlow: proc bugClient {299 sock276}
Jun 09 00:03:16 generalInfo: Cleaning Up…………..OK
tom@ubuntu-10:~/open-sapi/rockbox/wrap$

rbutil output:

[TalkGen] voicing: "Chase and Status & VC - The Grudge" to "/tmp/talkfiles/2601e5bc3ca57b017005c50e707f2941.wav"
[Opensapi] cmd: "outFile /tmp/talkfiles/2601e5bc3ca57b017005c50e707f2941.wav"
[Opensapi] answer: "202:Setting OK:outFile
"
[Opensapi] cmd: "speakMe Chase and Status & VC - The Grudge"
[Opensapi] answer: "201:Synth OK:
"
[TalkGen] voicing: "aa-chase_and_status-judgement_(informer)-sour" to "/tmp/talkfiles/89ba30fdfafb8f8fa8b9f6f6b7321478.wav"
[Opensapi] cmd: "outFile /tmp/talkfiles/89ba30fdfafb8f8fa8b9f6f6b7321478.wav"
[Opensapi] answer: "202:Setting OK:outFile
"
[Opensapi] cmd: "speakMe aa-chase_and_status-judgement_(informer)-sour"
[Opensapi] answer: "201:Synth OK:
"
[TalkGen] voicing: "a-chase_and_status-the_druids" to "/tmp/talkfiles/5eaa33e7dc41e3558da00a57dbf43e0e.wav"
[Opensapi] cmd: "outFile /tmp/talkfiles/5eaa33e7dc41e3558da00a57dbf43e0e.wav"
[Opensapi] answer: "201:Synth OK:
"
[Opensapi] cmd: "killServer"
[Opensapi] answer: "202:Setting OK:outFile
"
[Opensapi] unable to stop server "202:Setting OK:outFile
"
[Opensapi] old data detected: "299:Shutdown OK:
"
[Opensapi] cmd: "killServer"
[OpenSapi] serverCommand timout: ""
[Opensapi] unable to stop server ""

Updated Version uploaded to google with the changes we discussed.

I have not increased the format list return speed to about 0.5 of a second.

More observations:

The format list is displaying only odd entries in the list that the server returns. 1 , 3 , 5 ,7 so that needs a quick check

Rbutil does not seem to download the never version I am adding into google. I am incrementing the version number by one each time but it does not pick up the latest version.

New patch with fixed version checking and format list.

Is the above output log from a version with fixed speakMe command or not ?
Without fixed speakMe command i would expect that rbutil gets out-of sync, because then it wont wait long enough and gets confused by the additional answer.

   rbutil-opensapi6.patch (24.1 KiB)

Yeah that did include the change to speakMe:

I modified it to only return:
201:Synth OK

rbutil seems to give errors to the user after each file generation about not being able to set the outfile and actually does about 4 or 5 and then seems to die (which is 4 more than before), is there a time-out occurring or something?

Even in the first version rbutil gave error messages about the file being generated if it took longer and gave the outfile message as a error even though things were fine.

Then rbutil started to not generate files properly, this was with the original patch from the beginning on more recent build so I am not suprised about the problems but maybe something changes as you moved forward?

The format format list is coming back perfectly now :)
The method I have used is much more refined now and will be available on an update today.

Could you test it on windows for me as some point? I am interested to see if all the formats come back. Linux is limited at the moment but I am not sure if that is a bug in my code or if Linux/wine actually only supports one type. I seem to remember that in the past it has supported more but that might have been because I was using a bleeding edge version of wine. Confirmation from a windows box will show that the code is sound at least.

The version checking now seem to work and download and a few fixes my end have helped getting to server shutting down more reliably.

The only thing that is missing is the actual file generation :D the important bit :D

Great work !!!

Tom

Some more observations:

rbutil when running synthesis with open sapi is eating 195-197% of my cpu (2 cores). I have tested this with open-sapi running internally and externally and get the same behaviour.
rbutil seems to be eating cpu cycles like no bodies business to the point that the TTS generation is slowed right down to a crawl.

The open-sapi components will use available resources and is set to be low priority over other apps. The text to speech generation should be much faster and rbutil should be doing almost nothing but sending and listening for replys from the server and minding its own time-outs. Seems like it is rendering a new Hollywood blockbuster :D

T

Here are the logs for a failed generation run where rbutil is not segfaulting on me.

   rbutil-systemtrace.log (41.3 KiB)
   rbutil-gui.log (43.4 KiB)
   open-sapi-server.log (29.2 KiB)

This patch should fix the threading issue and make the voicing acutally work.
But it expects the older version of the server with the closeClient command still in place.

   rbutil-opensapi8.patch (25.6 KiB)

I have added the changes discussed onto Google.

It now renames rather than copies each generated file
Close Client is still included as per the old implementation
Linux/Win performance should be increased by about 25% removing a thread bug this will need addressing with a less hacky solution in the near future
Linux performance was then further boosted by using the latest PPA version of wine for Ubuntu (They are so behind!!)

A good nights work :)

T

Due to open-sapi taking a second or two to start-up on Linux I have found that if for example there is no work to be done. This happens when you choose create talk clips, with the just add new talk clips and there are no clips to be generated. In this senario open sapi is still started and the start-up delay before rbutil says finished straight away. I am being really picky here but if there is no work to be done maybe the TTS engine should not be started..? This might be hard work but just an idea.

T