This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11160 - Rbutil: Make TTS and encoders run on all cores
Attached to Project:
Rockbox
Opened by Delyan Kratunov (archivator) - Thursday, 01 April 2010, 01:43 GMT+2
Last edited by Dominik Wenger (Domonoky) - Friday, 04 June 2010, 23:24 GMT+2
Opened by Delyan Kratunov (archivator) - Thursday, 01 April 2010, 01:43 GMT+2
Last edited by Dominik Wenger (Domonoky) - Friday, 04 June 2010, 23:24 GMT+2
|
DetailsPatch 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, 23:24 GMT+2
Reason for closing: Accepted
Additional comments about closing: Just commited it.
Friday, 04 June 2010, 23:24 GMT+2
Reason for closing: Accepted
Additional comments about closing: Just commited it.
- 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.
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?
The function which startes the generation waits for != running,so i thought it should be safe to remove.
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.