From alsa-user-owner@alsa.jcu.cz  Thu Jan  7 20:25:36 1999
Received: from cutter-john.MIT.EDU (CUTTER-JOHN.MIT.EDU [18.70.0.158])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id UAA14175
	for <alsa-user@alsa.jcu.cz>; Thu, 7 Jan 1999 20:22:50 +0100
Received: (from xiphmont@localhost)
	by cutter-john.MIT.EDU (8.8.5/8.8.5) id OAA16632;
	Thu, 7 Jan 1999 14:22:40 -0500
From: Monty <xiphmont@mit.edu>
Message-Id: <199901071922.OAA16632@cutter-john.MIT.EDU>
To: Jaroslav Kysela <perex@jcu.cz>
Cc: alsa-user@alsa.jcu.cz
Subject: Re: 4 soundcards on a same machine and future of Multitrack 
In-reply-to: Your message of "Thu, 07 Jan 1999 19:56:51 +0100."
             <Pine.LNX.3.96.990107194645.2162B-100000@entry.jcu.cz> 
Date: Thu, 07 Jan 1999 14:22:40 EST
Reply-To: alsa-user@alsa.jcu.cz
Sender: alsa-user-owner@alsa.jcu.cz
Precedence: list


>> Because clocks drift.  The cheap clocks used in most computers and
>> sound cards will typically wander and drift several percent.  If you
>> record tracks on two different soundcards with a clock difference of
>> .5%, 10 minutes of audio will be out of sync three seconds at the end.
>
>Note that synchronization code should be in application code for ALSA
>driver which allows measure record start time and time in which will
>arrive next sample from kernel side ring buffer.
>
>This will allow to application start all record streams by independent
>ways and do some rate conversions plus sample skipping (to synchronize
>start of record stream). I know - this will be hard for coding, but
>useable without buying some special hardware or hacking kernel-side
>drivers.

Well, it's not the '100% Kosher' answer, but hacks to simulate the
functionality for folks with hardware that can't do hardware sync is a
good idea.  Having a reliable timestamp on incoming samples is a very
useful thing :-)

As for the above means of re-syncing two samples that have drifted,
dropped samples add spread-spectrum noise, and resampling at
non-integer or large integer ratios is incredibly expensive (unless
one doesn't care about S/N).  If the clock rate varies on either clock
(they do), then sync needs to be adjusted more continuously than just
a single linear adjustment for the whole track.  (this is just an
application aside.  It doesn't have much to do with the ALSA driver).

Dropping samples when the drift is only .001% is probably no biggie.
At 1%, it would be easily audible in pure tones.  At 5%, the sound quality
would really begin to suffer.

Monty


