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

[Jean-Marc Valin]

Andrew,

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
something similar.

Cheers,

	Jean-Marc

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.
> 
> -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 ...
> _______________________________________________
> celt-dev mailing list
> celt-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/celt-dev
> 
>