[Speex-dev] Major internal changes, TI DSP build change

[Jean-Marc Valin]

Jim,

The patches for bits.c, arch.h and speex_types.h applied fine, but the
ones for the files in ti/ (i.e. the project files and testenc-TI*)
didn't apply. Looks like a problem with the newlines (CRLF vs LF). Could
you send me an updated patch for that part? BTW, what I talked about
breaking down patches, I meant breaking down by functionality, not
necessarily by file. In this case, it could have been one patch for
bits.c, one patch with the stuff for arch.h and speex_types.h and one
patch for all the TI stuff in the ti/ directory.

	Jean-Marc

Le lundi 24 avril 2006 à 08:59 -0400, Jim Crichton a écrit :
> Jean-Marc,
> 
> Here are the patches, broken out one per file.  I did some additional work 
> in the testenc files based on Peter Mlakar's post to make it easier (though 
> still a bit klunky) to try different rates.
> 
> These changes also incorporate the file window.c into the builds, change the 
> decoder startup delay to account for the change in the algorithm delay from 
> 10ms to 5ms, and change bits.c to make the byte swapping uniform for the TI 
> C55 and C54 builds.
> 
> - Jim
> 
> 
> ----- Original Message ----- 
> From: "Jean-Marc Valin" <Jean-Marc.Valin at USherbrooke.ca>
> To: "Jim Crichton" <jim.crichton at comcast.net>
> Cc: <speex-dev at xiph.org>
> Sent: Thursday, April 20, 2006 7:13 PM
> Subject: Re: [Speex-dev] Major internal changes, TI DSP build change
> 
> 
> > Hi Jim,
> >
> >> Build 11169 in SVN works correctly.
> >
> > Good. I'll try not to forget the EXTEND32 from now on.
> >
> >> I have attached a zip file (renamed
> >> .txt) with a patch to bits.c to make the byteswapping for TI DSPs
> >> consistent.
> >
> > Seems like unzip can't read it. Either it's in an unknown format or the
> > file got corrupted. Could simply send as multiple (uncompressed)
> > attachments? BTW, broken down patches would be nice.
> >
> >> I also added a switch so that byte swapping could be enabled or
> >> disabled in config.h.
> >
> > Why would you want to turn it on/off?
> >
> >> There are also updates to the .pjt files to add
> >> window.c, and updates in the test main files in the TI directory to 
> >> account
> >> for the reduction in delay from 10ms to 5ms.  There is also an added 
> >> file:
> >> the C6x build needs speex/speex_config_types.h, so I created a speex
> >> subdirectory under TI with this file.  The subversion patch generation 
> >> tool
> >> would not handle an added file.
> >
> > Actually, speex_config_types.h is not necessary for the TI builds. It's
> > best to put the definition directly in speex_types.h.
> >
> >> I first made a patch against build 11146, applied this against 11169, 
> >> made a
> >> couple of other changes, and made a new patch agains 11169.  The second
> >> patch is larger because some line ends got changed in a couple of the 
> >> files
> >> when the first patch was applied.  I am sorry for the clutter, but its my
> >> first time with the patch tool.
> >>
> >> I have one lingering concern.  The C6x encoder does not produce the same
> >> results as the C55x and C54x.  The waveform reproduction is less accurate 
> >> as
> >> measured by a sample by sample comparison.  In the test programs, the SNR 
> >> is
> >> 11.10 in the C55x and C54x, and 10.79 in the C6x build.  I figured that 
> >> the
> >> encoders might not produce bit-exact results because of differences in 
> >> their
> >> wordlengths, but at one time they were the same (1.1.8, I think).  The
> >> decoders do produce the same results.  Do you think that this is anything 
> >> to
> >> be worried about?
> >
> > Yes, it worries me a bit. Not the fact that the SNR are slightly
> > different (one file is probably not enough to say which is "better"),
> > but the fact that they differ at all for the same fixed-point version.
> > Could you check when the results started being different. There might be
> > the same kind of error as earlier, but on a less critical bit of data.
> >
> >> Finally, in the simulator I measured the peak MIPs for the C55x as 29.4,
> >> where it was 41.5 in Speex 1.1.8.  I was expecting some improvement from 
> >> the
> >> continuing work you have been doing on the fixed point build, but this is
> >> really impressive, almost too good to be true.  This is all straight
> >> compiled C, after all (though the compiler has been updated also).
> >
> > I think this is probably due to some filters that got changed from
> > 32-bit accuracy to 16-bit. There is an option to use *all* filters with
> > 16-bit accuracy (just define PRECISION16) and I suspect the difference
> > wouldn't be very large. Note that the quality isn't be as good with that
> > option on, whereas the changes I made recently don't hurt quality.
> >
> > Jean-Marc
> >