David Kuehling wrote:
"Alan" == Alan W Black <[email protected]> writes:
David Kuehling wrote:
[..]
There is also AFAIK no Linux kernel support, so process switching
won't save/restore the simd register file. So no multi-tasking with
SIMD-using programs (at least not without weird side-effects).
Ok, this would make it very hard to use.
Not, not really. As you'd be the only one bothering with SIMD
instructions, nobody else would touch the register file, so your
application would run correctly :)
Hmm, "yes my code is thread safe, except for using global registers"
:-). I agree this might be possible and actually work but ...
As these SIMD instructions are completely proprietary I'd rather not
invest time into optimizing your code around them. What's the
problem with synthesis that is so CPU-intensive? Maybe some bunch of
hand-coded MIPS-assembler would already do the job? Or maybe some
algorithmic optimizations can solve the problem without resorting to
a "brute force" machine code optimization approach? Can you point us
to the specific C-code that needs tuning? Looks like a fun problem.
In statistical parametric synthesis, we use a computationally
expensive process called MLSA (cst_mlsa.c) with takes about 90% of the
time to synthesize.
Looking at
http://flite.sourcearchive.com/documentation/1.4-release-4/cst__mlsa_8c_source.html
I notice a lot of code does floating point computation? Is the floating
point part significant to total runtime? The Jz47xx does not have an
FPU, and the SIMD unit is also integer-only, so that won't help you
much. Recoding parts in integer arithmic might help if the float-part
has any significant impact on performance.
Yes it is floating point intensive. The non-mlsa code (the diphones and
unit selection) code uses almost no floating point and is integer
optimized, that does run fast enough on the Nanonote, but the synthesis
quality (and convenience) isn't as good.
It really needs about 800MHz (on an ARM) to be
real-time.
There are a lot of ARMs, some without FPU, some with crappy FPU
(e.g. imx51 with non-pipelined VFP unit). Some distributions' tool
chains won't even compile FPU instructions per default (Debian armel,
I'm looking at you :). Just to say, "800 MHz ARM" leaves a lot room for
speculation :)
I agree, but its my first threshold when people ask me what it needs.
With restricting the parameter order and number of other interesting
hacks we can get something fast enough on a 400MHz ARM (an HTC
TytnII). Although there probably is more optimization possible with
that algorithm, we've also been looking at different parameterization
of the speech, that still has the same predictive capabilities
(e.g. LSPs) but require less computation for resynthesis. The
Nanonote although *I*'d like that to work, 600MHz+ devices (Raspberry
PI, MK802 and various android phones) are probably our real target.
At first glance, HTC TytnII seems to have no FPU, BTW.
True, our tests were under WinCE using the mingw compiler and the soft
float emulation is actually ok.
Quite remarkable that something as low-data rate as speech-quality audio
is so difficult to generate...
Well us speech synthesis people seem to try to compete with speech
recognition people to use more CPU time :-). That's not quite true but
speech synthesis researchers rarely (except me) cares about end
processor performance. Signal generation for models is much harder than
simple signal reconstruction (like mp3 encoding, or simple LPCs)
It therefore might be more worthwhile to look for a better soft float
option. I remember back when we used ipaq 38xx's the floating point
performance under linux was much worse than the performance under WinCE
due to a better soft float optimization. Also I note how our
statistical synthesizers got much better on Google Nexus 1's when the
SDK compiler was upgraded to generate better float code.
But that would involve finding a mipsel optimized floating point emulator.
Alan
cheers,
David
------------------------------------------------------------------------
_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): [email protected]
Subscribe or Unsubscribe:
http://lists.en.qi-hardware.com/mailman/listinfo/discussion
_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): [email protected]
Subscribe or Unsubscribe:
http://lists.en.qi-hardware.com/mailman/listinfo/discussion
