[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