To better measure actual drift one has to use really good LPF, which means they have a pretty big delay.
So, it doesn't make sense to use a very good sample rate conversion because we learn bout the drift well AFTER it occurs. Good sample rate conversion makes sense only if clock frequencies of the cards are stable, though different. I think that, say, 4-th order Lagrange interpolation will be quite sufficient. Depending on the task one can have different approaches to rate conversion. For example, for real time monitoring one can use relatively low quality and low latency sample rate conversion, and simultaneously record all the separate streams separately with real time markers. Then, if, for example, a high quality recording should be produced from the streams, the streams can be sample rate converted using high quality rate converters and real time markers not in real time, and then downmixing can be performed as usual. On Mon, 2 Jan 2006 14:57:34 +0100 Asbjørn Sæbø <[EMAIL PROTECTED]> wrote: > On Fri, Dec 30, 2005 at 11:47:41PM -0500, Ross Vandegrift wrote: > > On Fri, Dec 30, 2005 at 05:42:32PM -0500, Lee Revell wrote: > > > LDAS (the low delay audio streamer) does something similar - it has to > > > compensate for the drift between two machines clocks' that exchange > > > audio over the network but you could apply the algorithm to two cards on > > > one box. It uses the ALSA API and is believed to accomplish this with > > > the lowest achievable latency. > > > > The site sounds like it mostly attempts to compensate for network latency, > > not clock drift between the hosts, though the PDF mentions some > > "watermark algorithm" (google didn't turn up anything relevant to > > timekeeping devices). > > Actually, we also try to compensate for clock drift, which _is_ a > problem. This is done by watching the (low pass filtered) length of > the receiver buffer. If the buffer grows, it is assumed that the > receivers sound card clock is slower than the senders, and vice versa. > The current solution is not very elegant, single samples are dropped or > reused as appropriate to keep the receiver buffer length withing given > bounds (the "watermarks"). A better solution, which I would like to > implement, is to use an (adaptive?) sample rate converter. Normally, an > SRC between two almost alike sampling frequencies (as we have here) > would demand long filters (and high latency). However, professor > Tor Ramstad at NTNU has written an article about how such SRCs may be > implemented in more efficient ways. > > Asbjørn > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
