[Jackrtp-devel] Re: [Jackit-devel] Jack RTP client
Status: Alpha
Brought to you by:
p_tisserand
|
From: Francois D. <Fra...@ir...> - 2004-07-29 13:26:46
|
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 |