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

[Gregory Maxwell]

On Mon, Nov 24, 2008 at 8:25 PM,  <torbenh at gmx.de> wrote:
[snip]
> ok. i overlooked that the minimum rate was 32kHz.

If you want to play around with it some you can remove the test around
line 321 in libcelt/modes.c.  The code will currently work down to
4kHz or so, but that is far outside of CELT's design target, it does
not perform well compared to other codecs (such as Speex), and it may
not work in the future.

If you find a good application for CELT at lower than 32kHz, I'd love
hear about it. If you're just looking for lower bandwidths you'll
probably get the best results using smaller frame sizes.

> for big samplerates i will do the downsampling using libsamplerate then.
>
> it already works like a charm.
> nice work guys :)

Be sure to account for whatever delay libsamplerate adds.

[snip]
> 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.

I'll let JM comment: I have no opinion on the API related to this.

[snip]
> 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 ;)

If you're just referring to samples in-out per period (VBR is okay)
then vorbis with some modifications to block switching might also suit
your application, but I expect JACK users are using -p 1024 or lower,
and probably most lower than 512? Which does leave you in the CELT
designed delay range.  FLAC also can give useful compression with very
small block sizes, though obviously not on the scale of the lossy
codecs.

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

I'd like to see it!

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

Oh, until this moment I had believe that netjack was timed purely from
one end and (accordingly) you wouldn't need jitter buffering.  I now
see you have a remote audio interface support. You might want to look
at the speex jitter buffer in -lspeexdsp.

I should warn you that delay compensation across the general internet
is major challenge: If the users are not on the same ISP the delay
will almost certainly be highly asymmetric, and it may even be
asymmetric even with a single ISP. You can't measure the delay split
without an accurate external reference.  I've done testing (using a
set of trimble thunderbolts as a absolute time reference) and found
that if you try hard you can sometimes get NTP to do the job (i.e. get
two internet separate end points into agreement within a couple of
ms), but usually it doesn't, and when it doesn't you can't tell
(except via a more accurate clock) you just get wrong results about
the delay split.