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

[Jean-Marc Valin]

Hi,

Responding to everyone at once...

torbenh at gmx.de a écrit :
> On Tue, Nov 25, 2008 at 08:36:39AM +0100, "Alexander Car?t" wrote:
>>> 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.
>> +1 ---  I do something similar to netjack (currently called
>> "Soundjack") in order to play live music on a network (
>> https://www.itm.uni-luebeck.de/users/carot/TMT08.pdf ).
>> 
>> My settings vary from 1024 down to 128 sample-blocks (depending on
>> the current network situation). CELT works excellent in that
>> context but it would be nice to have 1024 samples supported as
>> well.

I guess I'll have to think about it. Last time I checked, I found that
there was no gain in going above 512-sample frames because you easily
get pre-echo and the pitch predictor no longer works. Of course, one
possibility would be to pretend we're using 1024-sample frames and just
pack two 512-sample frames per packet.

> these tools use the soundcard dma buffer as "jitter buffer" they work
> very well under low jitter conditions, as seen, when using netjack
> with ethernet. i normally use 1024 samples as buffer.

Why not use a jitter buffer along with a smaller audio buffer. If you
look at the celtclient code (in the main repo under tools/), I use a
jitter buffer with just 256 sample audio buffer (could be made even
smaller). That would also help you handle lost/reordered/late packets
correctly. Also, it means that you can handle any amount of jitter
(adaptively) without requiring a large soundcard buffer.

BTW, what you are doing (syncing clocks across a net connection) is
similar to what PulseAudio does with network audio. Maybe there's
code/knowledge to share here.

> i am using linear resampling.
> but i will keep that in mind (hopefully  ;) 
> i will demand API changes to libsamplerate someday.
> i dont think it publishes its latency. 

Please don't use linear resampling, it harms animals (and my ears).
Using libsamplerate is an option (so is the Speex resampler), but I
think simply using a lower CELT rate might be better (and possibly faster).

Cheers,

	Jean-Marc