[opus] int operation

Jean-Marc Valin jmvalin at jmvalin.ca
Fri Aug 24 07:44:44 PDT 2012


Hi Mike,

It seems like the only way is again to fix one issue at a time. These
errors are pretty hard to detect when you're working with a 32-bit
platform. I think most of the variables use wide enough integer types,
but as you discovered, some intermediate results can overflow when
there's no implicit casting to 32-bit.

Cheers,

	Jean-Marc

On 12-08-23 11:42 AM, Mike Hooper wrote:
> Ralph, JM,
> 
> I am currently using Opus V1.0.1-rc and experience the problem stated
> earlier. It appears that we may have a similar issue to what we experience
> with CELT: much of the code assumes that in int is 32 bits. However, in the
> world of TI C55xx, an int is 16 bits. JM and I debugged much of CELT in
> March to fix these issues with CELT. Looks like we need to do the same with
> SILK.
> 
> Apparently some of the math calculations in SILK assume that frame_size is
> 32 bits, and hence cause errors. For example:
> 
> opus_int32 opus_encode(OpusEncoder *st, const opus_val16 *pcm, int
> frame_size, unsigned char *data, opus_int32 out_data_bytes)
> 
> The result of some operations on frame_size exceed 16 bits. Should
> frame_size be cast as opus_int32?
> 
> I would be happy to forge the way for debugging 16-bit architectures. How do
> we proceed?
> 
> Thx
> 
> MikeH
> 
> 
> -----Original Message-----
> From: Ralph Giles [mailto:giles at thaumas.net] 
> Sent: Wednesday, August 22, 2012 6:40 PM
> To: Mike Hooper
> Cc: opus at xiph.org
> Subject: Re: [opus] int operation
> 
> On 12-08-22 2:52 PM, Mike Hooper wrote:
> 
>> My TI C55xx complier is complaining about (in opus_encoder.c,
>> opus_encode()):
>>
>>         st->silk_mode.payloadSize_ms = 1000 * frame_size / st->Fs;
>>
>> where .payloadSize_ms is opus_int, frame_size is an int, and Fs is a
>> long. Should one of these be cast differently?
> 
> Fs should be an int instead of a long. It was changed to an opus_int32
> in September, so if you update to 0.9.7 or later the problem should go away.
> 
> I would suggest working with git master or the 1.0.1 release candidate
> source if you're doing a new port.
> 
>  -r
> 
> _______________________________________________
> opus mailing list
> opus at xiph.org
> http://lists.xiph.org/mailman/listinfo/opus
> 
> 
> 


More information about the opus mailing list