FS#11160 - Rbutil: Make TTS and encoders run on all cores

Attached to Project: Rockbox
Opened by Delyan Kratunov (archivator) - Wednesday, 31 March 2010, 23:43 GMT
Last edited by Dominik Wenger (Domonoky) - Friday, 04 June 2010, 21:24 GMT
Task Type Patches
Category Rbutil
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Rbutil SVN
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Patch 1 makes rbutil run the encoding process in parallel, on all cores. Tested with rbspeex, should work just as well with LAME.

Patch 2 makes rbutil run the Festival and TTSExes engines on all cores (Carbon needs reworking, SAPI doesn't look thread-safe - needs testing). The patch also introduces a very basic framework for the TTS engines to report their capabilities. Tested with Festival and espeak.

Naturally, there may be bugs but I think this is more or less the final solution to the problem (aside from cosmetic changes such as moving the extra members of TalkEntry to a new substructure).

Patch 2 cannot be applied without patch 1.
This task depends upon

Closed by  Dominik Wenger (Domonoky)
Friday, 04 June 2010, 21:24 GMT
Reason for closing:  Accepted
Additional comments about closing:  Just commited it.
Comment by Delyan Kratunov (archivator) - Wednesday, 31 March 2010, 23:45 GMT
Sorry, wrong file. Attached is the correct patch 1.
Comment by Delyan Kratunov (archivator) - Monday, 05 April 2010, 18:48 GMT
Some cosmetic fixes. This is the final patch, really. I can't think of any more functionality to add, so... I rest my case :)
Comment by Delyan Kratunov (archivator) - Tuesday, 06 April 2010, 19:45 GMT
This version fixes some tabs and a bug with duplicated entries. I also spotted a bug where refs.generator was not set for the voicing process, so the whole app would have crashed if the voicing failed.
Comment by Dominik Wenger (Domonoky) - Wednesday, 21 April 2010, 22:08 GMT
This version fixes the following problems:
- No progress Info with ttssapi. (changed waitForReadyRead to a polling loop in ttssapi::voice() )
- TTS Abort didnt work with ttssapi. (removed the waitForFinished() in Talkgenerator::abort() )

Also i think this patch needs testing with the other non-parallel TTS (TTSCarbon) before it can go in.
Comment by Delyan Kratunov (archivator) - Sunday, 25 April 2010, 00:09 GMT
Dominik, thanks for testing. I'll be setting up a VM soon to investigate SAPI further.

I have one objection to your changes, though. The second point in your comment must surely be a bug in ttssapi? After, all, all QFutureWatcher::cancel does is to signal the QFuture to stop sending new data to the child thread (meaning, wait for the current thread to finish and stop). waitForFinished() simply makes the call synchronous, so the problem lies deeper - perhaps something is keeping the child thread alive? Did you try breaking at TalkGenerator::abort in a debugger?
Comment by Dominik Wenger (Domonoky) - Sunday, 25 April 2010, 21:39 GMT
I didnt try it in the debugger, but the waitForFinished call blocked the whole UI, so generation either gets executed in the main-thread or there is some other threading/signaling problem.

The function which startes the generation waits for != running,so i thought it should be safe to remove.
Comment by Dominik Riebeling (bluebrother) - Sunday, 02 May 2010, 20:56 GMT
Fixed building on OS X. The changes to encoders.cpp are purely related to qDebug() output, so IMO those changes can go in immediately as separate commit.

I've tried building a voice file with the patch (05) and couldn't find any issues so far (the voice file seems to work fine, at least for the rather small amount of menu entries I've checked). Haven't looked in the code yet.