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

[Sumit Chatterjee]

Hi Gregory,
    Very informative explanation. According to your figures, my processor
stands nowhere close :(
     I have 2Ghz core2, but the time to encode 600-700ms data takes around
100ms and mostly more.
     Ofcourse the compilation has been improved to time based optimization.
i.e. O2

    Anyother updates that might help?

Thanks
Sumit


2009/9/4 Gregory Maxwell <gmaxwell at gmail.com>

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20090904/54b45a50/attachment.htm