[CELT-dev] Scanning the compressed celt for an artifact

[Andrew Lentvorski]

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 cards.


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 
screwy issues.

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.

-a


The *only* MP3 encoder chip I have found is here:
http://verkkokauppa.planeetta.net/epages/Planeetta.sf/en_GB/?ObjectPath=/Shops/vlsi/Categories/%22Circuits%20and%20KITs%22/VS1063

Good luck getting one out of them ...