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

[torbenh at gmx.de]

On Mon, Nov 24, 2008 at 08:04:33PM -0500, Gregory Maxwell wrote:
> 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?

ok. i overlooked that the minimum rate was 32kHz.
for big samplerates i will do the downsampling using libsamplerate then.

it already works like a charm.
nice work guys :)

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

ok. so i stick with my N encoders code.

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

ok... i guess i will implement this later.
is support for more then 512 sample blocks planned ?
i am putting one jack period of data into one packet.
so currently it only works with a period of <=512.
i could split that myself. but i dont see why the API should not handle
bigger blocks. and just hide the splitting to smaller blocks.

not sure if this would gain something quality wise.
the property netjack requires from the codec is that it has fixed
in:out ratio. so i guess celt is my only choice. and considering
how good this already works. will remain my choice ;)

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

thanks for the prompt reply.
are you interested in the patch ? i can post it here, if you like.

needs some cleanup until it gets committed into jack-svn but i expect
that to happen soon.

i need to fix alsa_in and alsa_out now, because they dont handle the big
timing jitter of an internet connection gracefully.

-- 
torben Hohn