[CELT-dev] Scanning the compressed celt for an artifact
jmvalin at jmvalin.ca
Sun Jul 17 17:48:53 PDT 2011
Let me assure you that if we really were "myopic about always being on
enormous machines", then you certainly wouldn't be able to use CELT :-)
That being said, it seems like what you're trying to do would be
achieved much more efficiently just by looking at timestamps or
On 11-07-17 06:14 PM, Andrew Lentvorski wrote:
> 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.
> The *only* MP3 encoder chip I have found is here:
> Good luck getting one out of them ...
> celt-dev mailing list
> celt-dev at xiph.org
More information about the celt-dev