[Speex-dev] Speex on TI C6x, Problem with TI C5x Patch
Jean-Marc.Valin at USherbrooke.ca
Tue May 24 22:38:28 PDT 2005
Thanks a lot for helping track problems with Speex.
> There is a bit of work remaining to get the memory usage down for a
> multichannel application. There have been some good posts over the
> last couple of months about reducing memory usage.
I think 1.1.8 incorporates all memory reductions proposed. Let me know
> Also, to nominally comply with the TI XDAIS algorithm standard, it is
> necessary to extract all of the memory allocation from the code,
> organize it into blocks, and provide a table to the application host
> with the size and scratch/persistent nature of each block. The host
> then does the memory allocating, and provides the pointers back to the
I'm not familiar with XDAIS, but I would think you could just overload
the speex_alloc() and speex_free() functions, right?
> The C5x has been another matter altogether. There were some build
> 1. The C54x compiler does not recognize "long long" and in fact does
> not support any 64-bit integer types. For the moment I am using
> "double" which maps to a 32-bit floating point on the C54x and C55x.
> The C55x compiler does support "long long".
> Question 1: Is there anything wrong with using a 32-bit float for
> spx_word64_t (other than MIPs)? This type is used only in two places
> in ltp.c.
No problem replacing with a float. The reason for the 64 bits is not the
precision but only the range. A 40-bit accumulator would work too.
Eventually, this could probably made to fit in a 32-bit int, but I
haven't done that yet.
> 2. I am not using the configure tools, so I needed to create
> speex_config_types.h (short and int are 16, long is 32 on C5x).
That, or you could add an entry in the speex_types.h file (which is used
for all platforms that don't use autoconf).
> 3. And, of course, the internal stack memory allocations in
> nb_encoder_int and nb_decoder_init had to be cut down to fit within
> the available data memory space. It would be useful to parameterize
> the working stack allocation size for those folks who cannot use the
> new VAR_ARRAYS and USE_ALLOCA stuff.
Would a compile-time option be OK (so I don't need to change the API)?
If so, I'll put that on the TODO list.
> After these changes the code built, but the encoder never returned.
> In bits.c, one of the changes from Jamey Hicks Speex 1.1.6 patch was
> lost in his 1.1.7 patch, and thus is missing in the 1.1.8 release.
> This causes an infinite loop when the code tries to pad the frame to
> the next char boundry. In the while loop in speex_bits_pack (line
Oops! It's now fixed in SVN.
> With this change, the codec ran, but the encoded data is garbage.
> Eventually I realized that because the char size on the C5x is 16
> bits, the fread and fwrite routines are using only the least
> significant 8 bits of each word. A little packing and unpacking
> later, the encoder/decoder loop was producing intelligible sound.
> However, there are some some anomalies. Using the sample file
> male.wav, the output has a positive step at 0.1 sec (rapid ramp from 0
> to ~20000 sample value, with decay back to zero by time 0.112 sec),
> another positive step at 2.940 sec (amplitude about 3000, decaying in
> 12 ms again), and a rail-to-rail impulse at 4.600 sec (also decaying
> within a few msec). This is a simulator, so there are no "real world"
> effects at play. The C6x simulation does not show the artifacts. The
> encoded bits are the same for the first frame, but then they diverge.
That's odd, definitely worth investigating.
> After some fumbling, I was able to extract the changed files from
> Jamey Hicks' original 1.1.6 patch, and this did not show the
> artifacts. However, the MIPs are too high for 1.1.6 (~285) and 1.1.8
> (~225), far exceeding the 160 MHz instruction rate the C54x processor,
> so I may have to abandon this part.
I remember sending to the list a corrected (so it still works on
"normal" machines) modified version of Jamey's patch a couple months
ago. Can you check if it has the artifact? Note that the bits.c bug is
probably in that patch too. IIRC, it applied to SVN just before 1.1.7.
> After some more fumbling, I got Speex running under the C55x
> simulator, and this produces the same (bit-exact) results as C54x for
> 1.1.8 and 1.1.6patch, although the MIPs are much better (56 for 1.1.6,
> 42 for 1.1.8).
I didn't understand. On the C55x, you're getting always good results or
> Question 2: Does anyone have any suggestions about where to start
> tracking down the artifacts? Speex does not use circular buffers, so
> I do not suspect a pointer wrap. I am fairly certain that the ALLOC
> stack is not running out. That would seem to leave arithmetic
> overflow, or some kind of unsigned-signed conversion problem. There
> have been many changes between 1.1.6 and 1.1.8, and nothing is leaping
> out at me from the Diff so far. The MIPs difference is significant,
> so it looks like some processing may have been simplified too much.
Actually, there's been some major optimization between 1.1.6 and 1.1.8.
Most of that was just before 1.1.7. As for a possible cause, it's hard
to tell. Here's a couple things I would suggest:
- Try defining FIXED_DEBUG and see if you have overflows (you'll
probably have to tweak fixed_debug.h first because it assumes int=32
- Try adding a "#define int long" or something like that in the C files.
- Since you're saying that the decoder is having the problem too (when
the file is correctly encoded), I suggest you focus on the decoder only,
since it's much simpler.
- One way to track differences would be to look at the exc signal at
different places (e.g. after the ltp_unquant, before and after the
I'm pretty sure it has to do with the fact that an int is 16 bits. Let
me know if you have any questions or if you find something.
Jean-Marc Valin <Jean-Marc.Valin at USherbrooke.ca>
Université de Sherbrooke
More information about the Speex-dev