On Tue, Jun 8, 2010 at 2:42 PM, Rafaël Carré <rafael.carre_at_gmail.com> wrote:

> Perhaps you're missing one important bit? Can you somehow profile which
> functions are the most expensive?

I don't think I'm missing anything, it's just that the code for that
particular engine was already pretty much entirely fixed-point. The rest is
just load/store operations which seem to be pretty fast anyway.

On Wed, Jun 9, 2010 at 6:55 PM, Mike Giacomelli <giac2000_at_hotmail.com>wrote:

Fragmentation is can be dealt with by freeing and reiniting everything like
> we do
> for codecs on track change.
>
> This is ugly, but for something like voice which is probably only active
> for 10
> or 20 seconds and then shuts down for several minutes or more, its probably
> not that
> big a deal. It'll be annoying to implement but the time average overhead
> will be
> quite small.

I was planning on doing that anyway. It's the fragmentation
*during*synthesis that's massive as it is. In one extreme case I
mapped out about
700 allocations of 12-byte structs (I was tracking them in particular). That
was just the initial steps, about 300 more memory operations before the
final cleanup. Sure, that was a synthetic case and it's impossible to arise
from any text in the English language but nevertheless it shows the issue
clearly. The speed was well below 0.5x realtime.

I realize it is kinda late in the program now but I wouldn't mind switching
to eSpeak. It's been proven to work, it's usable in theory, v1.26 should be
portable in practice. I was really hoping I could fight it off with flite
but what needs to be done is way over my head.

Regarding eSpeak, I just need to know what the situation with the licenses
is. In particular, can I use the code in the Flyspray issue or is that
strictly GPLv3? The patch is based on v1.28, so I'm in dark waters here, I
don't know how it works.

This is all if I'm allowed to switch targets, of course.
Received on 2010-06-11