Yes, the integer overflow was my first thought as well. I tested the the code on a PC with the "celtenc" and "celtdec" exe's. I assume if I configured the compilation with "--enable-fixed-point" that the behavior would manifest itself. It did not, so it may be an issue specific to the DSP. I can try to track this down, or I may upgrade the CELT revision. What revision contains the newer constraint on frame size? (The prime factors of 2,3 & 5) My system is quite defined on a 100 sample frame size so obviously that newer constraint won't work.<br>
<br>Also, in debugging my system I have seen that for a static frame input to the encoder, I see the exact same encoded buffer output , byte for byte, every call. Is this expected behavior? Is there no state information passed along to the decoder in the compressed buffer? So basically, for every input X[n], there is a defined output Y[n]?<br>
<br>thanks for getting back to me, I appreciate the help and love what you're doing here.<br><br><br><br><div class="gmail_quote">On Mon, Jan 31, 2011 at 9:46 PM, Jean-Marc Valin <span dir="ltr"><<a href="mailto:jmvalin@jmvalin.ca">jmvalin@jmvalin.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I guess the first question is whether you can reproduce the problem on a PC with the same code. If not, then the most likely issue is a 16-bit integer overflow. CELT *attmpts* to only use the "int" type for values that won't overflow a 16-bit int. However, because we have no 16-bit platform to test, it's likely that we missed something.<br>
<br>
Cheers,<br>
<br>
Jean-Marc<div><div></div><div class="h5"><br>
<br>
On 11-01-31 03:34 PM, Bob Bang wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><div class="h5">
Hi guys,<br>
<br>
I am on a C55x stereo implementation of CELT 0.7.1; I am using 100<br>
sample frame size and writing 58 Bytes per Packet. At the output of the<br>
decoder I see one channel reconstructed perfectly, but the other channel<br>
has random corruption that appears to be a sinusoid with a period of the<br>
frame size. The artifact is non-periodic and appears to happen randomly<br>
during the audio stream.<br>
<br>
Anyone ever run across this? Have any insight?<br>
<br>
thanks<br>
<br>
<br>
<br>
<br></div></div>
_______________________________________________<br>
celt-dev mailing list<br>
<a href="mailto:celt-dev@xiph.org" target="_blank">celt-dev@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/celt-dev" target="_blank">http://lists.xiph.org/mailman/listinfo/celt-dev</a><br>
</blockquote>
</blockquote></div><br>