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.<br><br>Regarding my platform:<br> - its on Windows and my encode is running under realtime priority.<br>
- my audio capture is every 500ms. <br> - And my OGG container is reduced to 2KB. So a min of 6KB data is flushed out after every ~600ms from the encoder<br><br>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.<br>
<br>Thanks<br>Sumit<br><br><br><div class="gmail_quote">2009/9/3 Gregory Maxwell <span dir="ltr"><<a href="mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Thu, Sep 3, 2009 at 2:26 PM, Sumit Chatterjee<<a href="mailto:getsumit@gmail.com">getsumit@gmail.com</a>> wrote:<br>
> Respected all,<br>
> I have been able to make my whole setup ready with OGG VORBIS encoder<br>
> and decoder as provided by the open source libraries. I am very happy with<br>
> the result. I have one concern in the same. : Can the performance of the<br>
> encoder be enhanced? Currently for 44KHz stream it is taking upto 300ms to<br>
> encode 500-600ms of data. I wanted a figure well within 500 ms.<br>
> Can I get a starting point that I can attack either in OGG library or in<br>
> VORBIS encoder library...??<br>
<br>
<br>
</div></div>Greetings. Is your concern algorithmic delay or computational<br>
complexity? If the latter— what platform are you testing on? The<br>
encoder is a decent multiple of realtime on typical desktop processors<br>
today.<br>
</blockquote></div><br>