[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:31:09
|
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 |