[CELT-dev] adding celt support to netjack some questions.

[Gregory Maxwell]

On Mon, Nov 24, 2008 at 7:49 PM, Jean-Marc Valin
<jean-marc.valin at usherbrooke.ca> wrote:
[snip]
> Actually, support for > 64 kHz would be relatively easy to do, although
> there would be no point in doing it other than convenience since the
> encoding would still stop at 20 kHz.

I expect that (2:1) resampling would be computationally cheaper than
running CELT at a higher rate.  Perhaps we should consider including
an internal resampler?

>> The CELT encoder currently supports stereo and mono modes. The stereo
>> mode is incomplete.  In my own app I have a separate add stereo add
>> mono mode. I think at this point it's overkill.
>
> Could you translate that to English? :-)

Sorry.  I mangled that in editing.

I have [add stereo channel] and [add mono channel] buttons in the app
and I create jack ports with L/R appended names in the stereo case.
You could support both channel types but I think that it's currently
not worth the effort (and more over, user interface complexity) even
in case where your audio is correlated.

>> CELT_GET_LOOKAHEAD should tell you the additional latency beyond a
>> single frame. but CELT delay is always 1.5x the frame_size today, I do
>> not expect this to change.
>
> Not only it's likely to change, but it never was the case. The delay is
> often 1.5x the frame size, but not for all frame sizes. For instance, at
> 512-sample frames, the look-ahead is 128 samples, so the total delay is
> 1.25x frame size.

Sorry, JM is right. Worse, I was the last person to edit the code
which selects the overlap.  I was having a blonde moment during my
reply.

>> You can select any even frame size, but power-of-two are recommended
>> (sizes with large prime factors have reduced quality right now).
>> Since you should probably make the CELT frame size either be equal to
>> or an integer factor of the Jack frame size in order to reduce latency
>> sticking to power-of-two CELT frames should be acceptable for your
>> purposes.
>
> Actually, I think you're still OK if you have a factor of 3 or 5 in the
> frame size, but large prime factors are indeed bad -- both for quality
> and for performance.

Right. Doesn't everyone know that they should read what I mean and not
what I say? — Thank you for your corrections.