[speex-dev] Speex test cases?

[Jean-Marc Valin]

Le dim 09/02/2003 à 21:50, John Hayes a écrit :
> I'm trying to get speex to encode a bit faster, mainly by rewriting a few
> functions in SSE and translating the GCC __asm__ to VC __asm.

Keep in mind that the SSE code is still experimental, even more so for
wideband. I'd suggest you first make sure you can get it to work
correctly under Linux.

> There's 2 functions I'm targeting, first is vq_nbest which consumes 40% of
> the time at high complexity and split_cb_search_shape_sign. Which consumes
> just over 30%. I've split out two functions from:

Regarding complexity, if you're tight on CPU, I don't suggest using more
than complexity 2. Even complexity 1 has quite decent quality. The
higher quality setting are mostly there if you can afford it and really
want to do all you can.

> cb_search_precompute_energy - loop at the comment:
> 	/* Pre-compute codewords response and energy */
> cb_search_update target - loop at the comment:
> 	/* New code: update the rest of the target only if it's worth it */
> 
> These functions represent 1/2 of the compute time at complexity 10 and 4/5
> at complexity 4.

Again, why do you need complexity 10. I'd say it's overkill in 99% of
the time (there's very little improvement between 5 and 10). 

> 1. I haven't been able to get the version of iir_mem2 in filters_sse.h
> translated and working. Does this work with GCC, I'm burning my eyeballs
> trying to spot the difference in my version.

As I said, I haven't really tested for wideband, so I suggest you try
them on Linux first. Otherwise, common problems when converting from gcc
to MSVC are (some may be obvious):
- make sure to load and store inputs/outputs correctly
- make sure to backup all registers that are modified by the asm code,
otherwise the compiler screws up because it expects that the asm doesn't
touch anything.
- gcc uses the AT&T syntax with "opcode src dest" while MSVC is "opcode
dest src"

> 2. I don't have a good source of wav data for testing. I've noticed that
> introducing bugs into speex (even gross ones like returning completely
> incorrect codebook entries) tends to, sometimes subtly, degrade quality
> instead of blowing up. Is there an existing set of source data - and maybe
> even a test harness that will do binary comparison, so I can avoid writing
> one?

The way I do that is I take a file (there are some on the site), encode
it and decode it and check the SNR I get. I then compare to an encoder
which is known to work. Note that in narrowband, there's a 80-sample
offset created by the codec, while in wideband it's 223 samples. Note
that you can't just do a bit-wise comparison because with floating
point, even different optimizations can make a difference.

> 3. I noticed the idea of a fixed-point version of speex on the webpage, what
> kind of performance difference is expected from that and are the value
> ranges already known?

The idea of having a fixed-point is not really to increase performance
but to allow Speex to work on platforms without an FPU, like PDA's.

        Jean-Marc


-- 
Jean-Marc Valin, M.Sc.A.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada

<p>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 242 bytes
Desc: signature.asc
Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20030209/e924255c/signature-0001.pgp