=?ISO-8859-1?Q?_Re=3A_=5Bspeex-dev=5D_Difference_in_Encoding_?=?ISO-8859-1?Q?of_files_on_Pocket_PC_vis-=E0-vis_desktop?In-Reply-To:
<1085699564.3286.8.camel@idefix.homelinux.org>
References: <6735222D09423F448E2A238E06D260F12F6DBE@inexg.GRAPECITY.NET>
<1085416539.4993.11.camel@idefix.homelinux.org>
<40B30D61.3080601@gerv.net>
<40B65BD9.2020904@gerv.net>
<1085699564.3286.8.camel@idefix.homelinux.org>
Message-ID: <40F54B90.10700@gerv.net>
Jean-Marc Valin wrote:> Right now, the code *does* assume that a char is 8 bits.
The decoder works on my [16-bit char] platform fine in floating-point
mode; it just fails in fixed-point mode. Should I be surprised at this,
or is that what you would expect?
> However, this
> assumption is only made in the bit packet (bits.c), so it should be
> fairly easy to make it work for a platform where a char is 16 bits.
So I would have to go through bits.c, work out which bits were 8-bit
dependent, and try and change them to work with 16-bit chars?
Is there any documentation on how bits.c works, at a high level? It
doesn't seem to have any comments in it.
Do you think it might be smart to attempt to get this working by, say,
using the Linux or Windows version and #defining "char" to
"short"? That
might be easier to debug than an embedded test board...
> Still regarding fixed-point, right now, spx_word_16 is defined as
> "short" and spx_word_32 is defined as "int", but
that's only in arch.h
> and eventually, it should be replaced by something a bit better.
That's probably OK; my shorts are 16 bits too, and I'm fairly sure my
ints are 32.
> Jean-Marc Valin
> http://www.xiph.org/~jm/
By the way, this URL is currently a 404...
Gerv
