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

[torbenh at gmx.de]

On Tue, Nov 25, 2008 at 07:14:05AM -0500, Jean-Marc Valin wrote:
> 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.

thats exactly what i propose.

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

well primarily... i am doing something different.
i am clocking a jack server on a slave machine, to the soundcard on the
master machine. the main use case is ethernet, where a second computer
can be dedicated to number crunching.
and its not even required to have a soundcard.

netjack is part of jack-audio-connection-kit
its implemented as a driver backend on the slave side.
i am not syncing clocks. i remove the necessity to sync clocks, because
there is only one clock.

that said: i have written alsa_in and alsa_out which can connect to the
soundcard of the slave machine. they can also connect to a second
soundcard, on a normal jackd.

alsa_in and alsa_out are normal jack clients. they just have their
process callback called, and then use snd_pcm_delay to measure
the jitter. i could go down to a delay of 12 samples in some ethernet
situations. 

Yesterday i have discovered celt and added support for it. i am now
trying to adjust this system to the new requirements.
Because its now possible to use netjack over the internet.

i dont want to force users to specific period sizes and stuff.
i can however recommend the users to use lower jack periods.


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

i am using libsamplerate. but the alsa_in and alsa_out tools are
intended for monitoring only. the regular signal flow of netjack
does not contain any resampling. because it only has one clock.


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language