Hi Ross,
It is indeed a known issue, although it's not easily addressable without
lowering the PLC quality. One thing you can play with is the LPC order.
If you look in plc.c, you can see:
#define LPC_ORDER 24
You can always reduce that and see if the quality and cpu are
acceptable. If the CPU is still too high (even with e.g. LPC_ORDER=2),
then you might need to either do some optimizations or just fill missing
frames with zeros.
In the end, the decoder complexity is so low that there isn't much you
can do in a PLC that doesn't require more computations than the decoder.
Cheers,
Jean-Marc
On 10-11-30 12:13 PM, Ross Bencina wrote:> Hello all
>
> Firstly thanks to everyone involved for creating CELT. It is really very
> useful :-)
>
> One of my targets is current generation Apple iPod with the fixed point
> decoder (latest version from website, 0.9.1)
>
> Based on my simple time-stamp based profiling of my running app it looks
> like decoding a null buffer for PLC costs a lot more than decoding a normal
> buffer. For example a standard decode takes about 1ms but the PLC decodes
> are predictably taking either 2.6ms or 4.4ms
>
> Is PLC inefficiency a known issue? Is there a way to get it to use the same
> amount of CPU as a normal buffer decode?
>
> I'm happy to help optimise or debug this.. I'm just not sure where
the best
> place to start is.
>
> Thank you
>
> Ross.
>
> _______________________________________________
> celt-dev mailing list
> celt-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/celt-dev
>
>