[Speex-dev] Major internal changes, TI DSP build change
Jean-Marc.Valin at USherbrooke.ca
Mon Apr 24 20:56:51 PDT 2006
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.
Le lundi 24 avril 2006 à 08:59 -0400, Jim Crichton a écrit :
> 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
More information about the Speex-dev