[CELT-dev] C55x Fixed Point PLC Stack Usage and Audio Quality
jmvalin at jmvalin.ca
Tue Sep 20 07:25:39 PDT 2011
It's likely that you hit one (of possibly many) case where we use an
"int" even though we need more than 16 bits. We've tried being careful
about those and using a 32-bit int type instead, but the problem is that
we have no way of testing that our code works on machines with 16-bit ints.
About the PLC, you can indeed call it any number of times you want and
it should eventually decay to the level of the background noise. Do the
encoder and decoder work fine otherwise? It's hard for us to debug, but
maybe you can compare the behaviour you get on the C55x to what you get
on a PC and see where the two diverge. It should all be trivial to fix
once the problems are identified.
On 11-09-19 05:09 PM, Bob Bang wrote:
> Hello everyone, I just wanted to see if anyone else is using PLC on the
> C55x and having success? I am seeing some issues and was curious if I
> was doing anything wrong/stupid or maybe I have found a bug?
> I am using:
> * the CELT library from OPUS 0.9.5 ( I checked the git repo and no
> check ins have comments about PLC, I assume it hasn't been updated)
> * FRAME_SIZE: 240
> * PACKET_SIZE: 40
> * SAMPLE_RATE: 48000
> * TI 5509, 5505, 5504
> To utilize the PLC functionality I pass a NULL pointer in place of the
> buffer of encoded bytes. At first my program would crash, but realized
> PLC was eating up my entire stack. PLC required I provide the stack an
> additional 0x900 bytes (2300 bytes) to not crash. That sounds fishy.
> Also, is there a correct method to calling PLC? Is there a limit to the
> number of times you should call it consecutively? Can I only call it
> once per so many packets? It is supposed to fade out? When I believe PLC
> is working correctly, I get what sounds like a repeated buffer of
> constant level noise similar in character to the audio at the time of
> passing the NULL pointer.
> Any one have any insights? Does PLC on the TI platform work like this
> for you?
> Thanks as always,
> celt-dev mailing list
> celt-dev at xiph.org
More information about the celt-dev