[Tremor] "Bursty-ness"

[Jim Barlow]

Vorbis packets typically encode 2048 or 64 samples, 2048 being most
common and 64 for transients.  The data is encoded using a MDCT (check
Wikipedia) so the data required to reconstruct each of the original 2048
samples is split across frequency bands and can only be reconstructed as
the complete 2048 block.  A certain degree of "bursty-ness" is a
fundamental characteristic of any frequency domain algorithm.

If you ask for 128 samples, then the decoder will decode 2048, return
128, and let the remainder sit in buffer, which more or less explains
the peaks.  After decoding, all that's required is a buffer copy.  If
you ask for larger sample blocks (e.g. much larger than the packet
size), the decode time approaches constant but the delay may not permit
real-time operation.

I suppose the best answer to smoothing out decode time is to use a
pre-emptive RTOS.

Have you applied the patches listed on the mailing list?  The SVN branch
has not been updated in a long time, so you have to apply a number of
patches yourself.  I don't know if any affect performance but it would
be worth fixing before you proceed further.

Jim

-----Original Message-----
From: tremor-bounces at xiph.org [mailto:tremor-bounces at xiph.org] On Behalf
Of Darren Gibbs
Sent: Monday, August 27, 2007 17:21
To: tremor at xiph.org
Subject: [Tremor] "Bursty-ness"

We're evaluating tremor for use in an upcoming product, and after doing
some performance analysis, have discovered that it is surprisingly
bursty.  Reducing the number of samples requested helped, but still...
the time required to return a block of 128 samples can differ by a
factor of 100.  Is this typical/expected?  Has anyone experimented with
strategies for smoothing out the decode time?

thanks,

darren
_______________________________________________
Tremor mailing list
Tremor at xiph.org
http://lists.xiph.org/mailman/listinfo/tremor