[Vorbis-dev] any optimizations possible in OGG or vorbis to reduce time?

Gregory Maxwell gmaxwell at gmail.com
Thu Sep 3 12:28:41 PDT 2009


On Thu, Sep 3, 2009 at 2:44 PM, Sumit Chatterjee<getsumit at gmail.com> wrote:
> I dont understand exactly the terms that you have asked. Basically if I have
> a continuous stream to be sent out - a computational delay of 50-100ms is
> still manageable.
>
> Regarding my platform:
>    - its on Windows and my encode is running under realtime priority.
>    - my audio capture is every 500ms.
>    - And my OGG container is reduced to 2KB. So a min of 6KB data is flushed
> out after every ~600ms from the encoder
>
> I basically want to reduce the encoding time to generate a packet of 6KB
> from 200-300 ms to <100ms always, so that I can support least setup latency
> in my radio application.

Algorithmic delay is the amount of intrinsic delay in the algorithm
which comes from things like the blocksize and the data look-ahead.
It can't be fixed by applying a faster processor, it can sometimes be
reduced with a carefully written software but some amount of
irreducible delay will exist in the format.

Computational complexity is just the delay that comes from the
computer executing your instructions. A faster processor or more
efficient software addresses this.

The vorbis format is not particularly designed for low algorithmic
delay, nor is the reference encoder designed to minimize delay to the
minimum possible in the format but it sounds like you expecting to use
large blocks of audio and can tolerate the fairly high algorithmic
delay of the normal vorbis modes, so your problem is complexity.

I should have been more specific:  What processor is in use?   Is your
problem a problem with the average encoder execution time or the worst
case encoder execution time?   On average my 1.6ghz core2 laptop
encodes at >17.5x realtime, or 500ms of audio encoded in ~29ms.  But
this is the average, I expect the worse case is much worse.

If you're seeing average performance worse than this on comparable
hardware perhaps there is an issue with how you are calling libvorbis
or with how it was compiled.


More information about the Vorbis-dev mailing list