[Speex-dev] re: decoder issue in sb_celp
Jean-Marc Valin
jean-marc.valin at usherbrooke.ca
Wed Mar 14 19:08:18 PDT 2007
> I don't think that the stack is getting corrupted- but I can't
> rule it out- so what I will do is try to record some
> samples to a file to reproduce this outside of the app.
> Is there a standard place to post test files?
It would indeed be much easier to deal with a stand-alone file. If
possible, please upload it to a website and send the URL. Otherwise,
just send it to me privately (the list has a limit of 40 kB or so).
> Note also I am intentionally stressing out speex here in
> part to figure out what the issue is- 99.9% of the time
> this issue never happens but right now it is not possible
> to recover from it when it does.
Well, it should definitely work 100% of the time.
> The input to the LPC code is valid as far as I can tell,
> if a little large.
What do you mean large? The input to lsp_to_lpc should be between 0 and
pi in the floating-point version.
> The specific test case is that when a CPU gets spiked to
> 100% (which can happen) the audio captured can end
> up not being contiguous - ie. you'll have a set of samples
> then a gap and then another set of samples. So what
> usually happens is speex will (correctly) generate a large
> pop in its decoded audio and then go on its merry way.
Well, better to avoid these situations, although they shouldn't be
affecting Speex.
> Some of the time, however, the decoder gets in a bad
> state- and then the decoded audio is always silent after
> an initial pop sound.
So you're telling me that the problem only occurs when there's a gap
(overrun) on the encoder side?
Jean-Marc
More information about the Speex-dev
mailing list