[CELT-dev] Scanning the compressed celt for an artifact
bsder at allcaps.org
Sun Jul 17 15:14:56 PDT 2011
On 7/17/11 7:20 AM, Benjamin M. Schwartz wrote:
> Recent versions of CELT have a special case for exact digital silence, and
> will generally produce identical output for all-zeros input. Note that
> this only applies to packets whose entire window is zero, including the
> last 2.5ms of the preceding frame.
> I think your use case is very strange. Since CELT's latency is a known
> constant, you could just look at packet numbers to determine the rest of
> the system's latency. Alternatively, you could just send pre-encoded
> packets with known contents.
Um, you folks who develop CELT really are myopic about always being on
enormous machines with huge storage, RAM, etc. ;)
This is a microcontroller system. It's not always easy to bend it in
ways that make debugging easy ... storing lots of packets is *not* in
The issue is that I have a CELT system that is exhibiting enormous
latency--I am fully aware that this is not the fault of CELT. It could,
however, be something at fault on the board. The CELT compression is
taking approximately 80% of the total available CPU, so it would not be
impossible for something to come in and push that over 100% and cause
Audio In -> Codec -> CELT encode -> Ethernet Out is under my control. I
can calculate all of those latencies as they are deterministic.
However, I really need something that shows "audio in changed here->
corresponding CELT packet fell out here".
After examining the CELT streams a bit, I'm probably just going to flag
significant compressed stream *length* changes. It seems that if you
feed in a sine wave the packet length settles to a fairly constant
number +- a little. When you shift that frequency, there is a sudden
jump in the packet length which then settles down again.
And, while I was being a bit flippant about CELT developers focusing on
large machines, if folks want CELT adoption, pushing at the embedded
people is the way to do it. Being able to store things like sound
effects in compressed form and expand them with *low latency* is a big
deal on handheld devices. Hitting storage on a lot of handhelds is
*enormously* slow, so being able to hold those sounds in CELT form in
RAM until needed is huge--it allows folks to use many more/longer sound
effects. The fact that CELT is CPU friendly is another huge bonus in
the battery driven arena.
The other side of that is that there exist *no* useful hardware encoder
chips for MP3 or Ogg. CELT + low end microcontroller is way cheaper
than the only chips that currently exist (presumably the MP3 license
causes this). I already shoved aside an MP3-based project because I can
*destroy* the price point. I suspect I'm going to bash two others
shortly. Yes, they should be using Vorbis; however, even if they were
using Ogg I could probably beat their price point. Both MP3 and Vorbis
require non-trivial amounts of CPU and RAM to encode.
The *only* MP3 encoder chip I have found is here:
Good luck getting one out of them ...
More information about the celt-dev