<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2627" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>I am working on Speex builds for the TI C64x and
C54x DSPs. I am running 8kbps, complexity 1, under the TI Code Composer
simulator.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The C64x was straightforward, thanks to the work
that has gone before. To get a test to run in the simulator, all that I
had to do was modify the testenc.c file to replace the parameters to main() with
fixed filenames (and change enctest.c to open the files as binary), and it built
and ran (an older version of the Code Composer Studio tools did not recognize
the type "long long", but "double" was okay). Mind you, it took
1800 MIPs for 8kbps, complexity 1. Eventually I figured out that the
FIXED_DEBUG define adds range checking to all of the computation macros.
After getting rid of this, and turning on the compiler optimization, the MIPs
dropped to ~37. This is low enough to run 15 or so channels on a 600 MHz
DSP, which is not bad. 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. 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 application.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The C5x has been another matter altogether.
There were some build issues:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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".</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>After these changes the code built, but the encoder
never returned. </FONT><FONT face=Arial size=2>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 246):</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>
bits->chars[bits->charPtr] |=
bit<<(7-bits->bitPtr);<BR>
bits->bitPtr++;</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> if
(bits->bitPtr==8)<BR></FONT></DIV>
<DIV><FONT face=Arial size=2>should be:</FONT></DIV>
<DIV><FONT face=Arial size=2> </DIV></FONT>
<DIV><FONT face=Arial size=2>
bits->chars[bits->charPtr] |= bit<<(BITS_PER_CHAR-1 -
bits->bitPtr);<BR>
bits->bitPtr++;</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> if
(bits->bitPtr==BITS_PER_CHAR)<BR></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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). </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I have tried encoding with 54x and decoding with
64x, and vice versa. Both of these combinations show artifacts, although
the 54xEnc/64xDec definitely looks better. I have considered shifting the
audio in the input file, to see how the position of the artifacts moves, but I
have not tried this yet.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>- Jim Crichton</FONT></DIV></BODY></HTML>