[CELT-dev] V0.8.0 Problems

Jean-Marc Valin jean-marc.valin at usherbrooke.ca
Tue Jul 6 17:38:05 PDT 2010


Hi Mike,

On 10-07-06 08:10 PM, Mike Hooper Hooper wrote:
> Now on to a rather simple fix. In vq.c my compiler complains about
> #ifdef FIXED_POINT
> int k = celt_ilog2(E)>>1;
> #endif
>
> being placed after an executable statement. Apparently this is OK for
> C++ but not C. I moved this up just after E=EPSILON and my compiler quit
> complaining.

Just checked in a fix for that.

> Next, there appears to be a problem between my dsplib.h and plc.h and
> plc.c. I get ther following error messages:
>
> In plc.c
>
> "declaration is incompatible with "ushort fir(DATA *, DATA *, DATA *,
> DATA *, ushort, ushort)" (declared at line 50 of "..\libcelt\dsplib.h")
> libcelt80/libcelt plc.c line 97 1278460811593 9315"

I assume dsplib.h also defines a (different) fir() function. Maybe 
there's a way to change the CELT TI headers to not include dsplib.h in 
this particular context?

> all of which seem to be related to an incompatible type.

No, it's just two unrelated functions with the same name.

> ...also, I tried to #undef NEW_PLC in my config.h but it did not exclude
> these files.

NEW_PLC is now the only PLC, so the macro doesn't even exist in 0.8.0.

Cheers,

	Jean-Marc

>
> *
> *
>
> *
> *
>
>
>
> ------------------------------------------------------------------------
> *From:* Jean-Marc Valin <jean-marc.valin at usherbrooke.ca>
> *To:* Mike Hooper Hooper <mihooper at bellsouth.net>
> *Cc:* celt-dev at xiph.org
> *Sent:* Tue, July 6, 2010 7:40:20 PM
> *Subject:* Re: [CELT-dev] V0.8.0 Problems
>
> OK, I think I just fixed half of the issue, but is it possible that you
> were not using the latest git? I committed a fix yesterday that seemed
> like it should have fixed the other half of the issue you're having.
>
> Cheers,
>
> Jean-Marc
>
> On 10-07-06 07:16 PM, Mike Hooper Hooper wrote:
>  > Jean-Marc,
>  > I have a few more that could be similar:
>  > In celt.c, in celt_decode_float, in the return statement
>  > "*return* celt_decode_with_ec_float(st, data, len, pcm, frame_size,
>  > *NULL*);"
>  >
>  > ...my compiler says
>  >
>  > "argument of type "float *" is incompatible with parameter of type
>  > "celt_sig *restrict" libcelt80/libcelt celt.c line 1888 1278457880500
> 9106
>  >
>  > However, in my config.h file I have :
>  >
>  > * *
>  >
>  > *#define* DISABLE_FLOAT_API
>  >
>  > * *
>  >
>  > *#define* FIXED_POINT
>  >
>  > Did I miss a #define somewhere?
>  >
>  > thx
>  >
>  > Mike
>  >
>  >
>  >
>  >
>  > ------------------------------------------------------------------------
>  > *From:* Jean-Marc Valin <jean-marc.valin at usherbrooke.ca
> <mailto:jean-marc.valin at usherbrooke.ca>>
>  > *To:* Mike Hooper Hooper <mihooper at bellsouth.net
> <mailto:mihooper at bellsouth.net>>
>  > *Cc:* celt-dev at xiph.org <mailto:celt-dev at xiph.org>
>  > *Sent:* Tue, July 6, 2010 7:04:42 PM
>  > *Subject:* Re: [CELT-dev] V0.8.0 Problems
>  >
>  > Hi Mike,
>  >
>  > Thanks again on that other bug. It turns out that on most platforms
>  > "celt_int32" is the same as "int" so the compiler doesn't complain.
>  > Unfortunately, I haven't found any way to test for these kinds of issues
>  > that happen only on 16-bit platforms and I've had to rely on people like
>  > you compiling on such platforms. Let me know if you find anything else.
>  > This one is now fixed in git.
>  >
>  > Thanks,
>  >
>  > Jean-Marc
>  >
>  > On 10-07-06 06:22 PM, Mike Hooper Hooper wrote:
>  > > Jean-Marc,
>  > >
>  > > I wish I could take credit for finding the bug, but I'll have to give
>  > > credit to my compiler....:)
>  > >
>  > > Let's now take a look at this code in bands.c
>  > >
>  > > " quant_band(encode, m, i, X, Y, N, b, spread, tf_change, lowband,
>  > > resynth, ec, &remaining_bits, LM, norm+M*eBands[i], bandE, 0);"
>  > >
>  > > My compiler says:
>  > >
>  > > "argument of type "int *" is incompatible with parameter of type
>  > > "celt_int32 *" libcelt80/libcelt bands.c line 951 1278452093812 9084"
>  > >
>  > > I'm not exactly sure where the problem is. Can you see it?
>  > >
>  > > MikeH
>  > >
>  > > -----Original Message-----
>  > >
>  > > From: Jean-Marc Valin [mailto:jean-marc.valin at usherbrooke.ca
> <mailto:jean-marc.valin at usherbrooke.ca>
>  > <mailto:jean-marc.valin at usherbrooke.ca
> <mailto:jean-marc.valin at usherbrooke.ca>>]
>  > >
>  > > Sent: Tuesday, July 06, 2010 6:00 PM
>  > >
>  > > To: Mike Hooper Hooper
>  > >
>  > > Cc: celt-dev at xiph.org <mailto:celt-dev at xiph.org>
> <mailto:celt-dev at xiph.org <mailto:celt-dev at xiph.org>>
>  > >
>  > > Subject: Re: [CELT-dev] V0.8.0 Problems
>  > >
>  > > Hi Mike,
>  > >
>  > > Indeed, you found a bug! I missed it because the symptoms you saw only
>  > >
>  > > occurs in fixed-point with compilers that don't have var arrays or
>  > >
>  > > alloca(). It's fixed in git now. For now (commit b6a5f9), the git
> master
>  > >
>  > > branch is bitstream compatible with 0.8.0. I'll probably issue a 0.8.1
>  > >
>  > > bugfix release after we fix any remaining problems you have.
>  > >
>  > > Cheers,
>  > >
>  > > Jean-Marc
>  > >
>  > > On 10-07-06 04:52 PM, Mike Hooper Hooper wrote:
>  > >
>  > > > Tim, et al,
>  > >
>  > > > I have run into several problems with V0.8.0. I will address them
>  > >
>  > > > seperately.
>  > >
>  > > > 1. My compiler is complaining about the following code in celt.c
> which
>  > >
>  > > > seems to define metric first as celt_word32, then as celt_word16.
> Am I
>  > >
>  > > > mis-interpreting something?
>  > >
>  > > > VARDECL(celt_word32, metric);
>  > >
>  > > > ALLOC(metric, len, celt_word16);
>  > >
>  > > > Thx
>  > >
>  > > > MikeH
>  > >
>  > > >
>  > >
>  > > >
>  > >
>  > > >
>  > >
>  > > > _______________________________________________
>  > >
>  > > > celt-dev mailing list
>  > >
>  > > > celt-dev at xiph.org <mailto:celt-dev at xiph.org>
> <mailto:celt-dev at xiph.org <mailto:celt-dev at xiph.org>>
>  > >
>  > > > http://lists.xiph.org/mailman/listinfo/celt-dev
>  > >



More information about the celt-dev mailing list