From alsa-user-owner@alsa.jcu.cz  Thu Jan  7 22:45:37 1999
Received: from gaia.rus.uni-stuttgart.de (gaia.rus.uni-stuttgart.de [129.69.1.136])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id WAA24318
	for <alsa-user@alsa.jcu.cz>; Thu, 7 Jan 1999 22:42:53 +0100
Received: from vulcain.yyydom (vulcain@gw-21.wh.uni-stuttgart.de [129.69.166.242])
        by gaia.rus.uni-stuttgart.de (8.8.8/8.8.8) with ESMTP id WAA07794
        for <alsa-user@alsa.jcu.cz>; Thu, 7 Jan 1999 22:43:44 +0100 (MET)
        env-from (erikyyy@studbox.uni-stuttgart.de)
Received: (from erik@localhost)
	by vulcain.yyydom (8.9.1a/8.9.1/Debian/GNU) 
	id WAA28974  for alsa-user@alsa.jcu.cz; Thu, 7 Jan 1999 22:42:23 +0100
Date: Thu, 7 Jan 1999 22:42:23 +0100
From: Erik Thiele <erikyyy@studbox.uni-stuttgart.de>
To: alsa-user@alsa.jcu.cz
Subject: Re: 4 soundcards on a same machine and future of Multitrack
Message-ID: <19990107224223.A28960@vulcain>
References: <Pine.LNX.3.96.990107194645.2162B-100000@entry.jcu.cz> <199901071922.OAA16632@cutter-john.MIT.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <199901071922.OAA16632@cutter-john.MIT.EDU>; from Monty on Thu, Jan 07, 1999 at 02:22:40PM -0500
Reply-To: alsa-user@alsa.jcu.cz
Sender: alsa-user-owner@alsa.jcu.cz
Precedence: list

On Thu, Jan 07, 1999 at 02:22:40PM -0500, Monty wrote:
> 
> >> 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.

if clocks drift only a _little_ bit, you will notice heavy annoying
surround effects! the slightest clock drift is audible, if several channels
carry some kind of same signal. (e.g. quadro stereo recording of an
orchestra with 4 microphones in the room. the surround effects will be so
sucking that you really do not want to have unsynced clocks anymore)

do not believe ? then record a mono stream and write little
ALSA application that plays SAME stream on two different soundcards
at the SAME time. use two speakers and listen carefully :-)
quite early (maybe 2 seconds after start) you will notice that something's
wrong with placement of sound, you start to think that sound origins
from other place than before. sound will move farer and farer off into
distance (it's worth playing with these effects) afterwards you will
think that it is some kind of roboter voice, or echo. and then it will
be just terribly annoying.

what i wanted to say is that you can calculate away the problems.
but the slightest incorrectness results in unwanted surround effects.
so, if two channels carry the approximatly same signal (like in stereo)
they MUST be on the same clock chip. of course if soundcard 1 plays
the drums and soundcard 2 the music, you will notice no difference
between real 4 channel 1 clock card    and  two cards with 2 channels each
and 2 clocks. (because the audio signals have nothing in common)

just my 2 cents :-)

cu
erik

--
EMAIL: erikyyy@studbox.uni-stuttgart.de                  \\\\
       thieleek@tick.informatik.uni-stuttgart.de         o `QQ'_
IRC:   erikyyy                                            /   __8
WWW:   http://wwwcip.rus.uni-stuttgart.de/~inf24628/      '  `
       http://tick.informatik.uni-stuttgart.de/~thieleek/

