jackrtp-devel — JACK RTP client development discussion

[Jackrtp-devel] Current Status of jackrtp

[<ia...@g7...>]

Hi,

What is the current status of jackrtp ? Does it compile ? Work ? I'm
currently using jack.udp, but would like to try using RTP - would seem 
to make more sense than just pure UDP...

I checked the list archives, but it looked like the last post was in
July 2004, with the last cvs commit in August 2004...


Iain

[Jackrtp-devel] Re: [Jackit-devel] Jack RTP client

[Francois D. <Fra...@ir...>]

Le jeu 29/07/2004 =E0 02:41, Anders Johansson a =E9crit :
> Hi,
>
> [...]
>=20
> I have been looking at this problem prevously (mplayer using multiple
> sound cards for playback). In mobile telephony a voise activity
> detector is used and the sample clock diference is compensated for
> during periods of scilence. Here the problem is harder since the
> stream is continous. There are two ways that I can think of to
> estimate the clock drift:
>=20
> 1. Use a common clock reference like GPS or an NTP server to
>    calculate the sample rate difference.
> 2. Estimate the drift by measuring buffer over and under fill, and use
>    some kind of model to lower the variance in the estimate. An AR0
>    model is often good for this type of estimation.
>=20
> In my experinece the sample rate difference is very small which means
> that one only have to comentsate by less than 10 samples per
> second. This type of resampling is easiest to do with linear
> interpolation since a polyphase filterbank will be too big (and will
> have to be redesigned on the fly). Any smoothing necessary can be done
> using alow pass filter with a cutoff frequency very close to half the
> sample rate. If higher sound quality is necessary use combination of
> resampling and linear interpolation where the incomming signal is
> uppsampled two - four times, linear interpolation is applied,
> whereafter downsampling back to the original samplerate is done. Only
> one FIR filter is necessary and it can be implemented as a polyphase
> filter. For source code on linear interpolation and polyphase filter
> bank resampling see libaf in the mplayer source tree.
>=20
> Hope this helps,
> //Anders

Yes it does. Thanks a lot.

As I said in my previous mail, we first fix the urgent issues
(compilation and others) and then we jump on the clock drift issue.

I think that the second way of estimating the drift is reasonnable. My
idea was to use the RTP time stamps to do the estimation (I'm wondering
whether this will work only if the source and the destination agree on
the unit of the timestamps?).

fd

[Jackrtp-devel] Re: [Jackit-devel] Jack RTP client

[Francois D. <Fra...@ir...>]

Le jeu 29/07/2004 =E0 02:16, Fons Adriaensen a =E9crit :
> On Wed, Jul 28, 2004 at 03:54:38PM +0100, Steve Harris wrote:
>=20
> > I haven't yet tried Fons's DLL implementation, but he seemed pretty
> > confident in it. Assuming the clock-drift-drift (drift of the drift -=
 is
> > there a word for that) is pretty small it should be OK IIUC.
>=20
> That's correct. The real problem is estimating this drift, and that's
> where all the problems start to appear. The actual resampling is just
> a matter of compromise between accuracy and CPU load. In practice,
> cubic interpolation will probably do nicely.
>
> [...]

Thanks a lot for the explanation. To be honest, I need to go back to it
with a fresh head ;-) and then I will for sure have more questions.

We are currently setting up the project on sourceforge. The code is in
cvs, the mailing lists are here. Once we have something that compiles
and runs, we jump into the clock drift problem.

I had an idea, which may be stupid, but who knows? Instead of resampling
all the incoming streams all the time, would it be possible to resample
only a subset, with a non-constant resampling factor that is grosso modo
multiplied by a hamming window, using a set of delayed hamming window
like in classical overlap and add methods. This way, you have only a few
resampling going on at the same time. I'm curious to have your opinion
about the audio consequence...

fd