Re: [ecasound] full-duplex sync

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] full-duplex sync
From: Kai Vehmanen (
Date: Sun Oct 14 2001 - 16:57:18 EEST

On Fri, 12 Oct 2001, Jeremy Hall wrote:

[ecasound's multitrack-sync]
> It works until a person wants to use the live signal as a base to work
> from. The track drift I have noticed seems to be related to the
> frames_per_cycle and if there are many tracks that were recorded
> separately, the drift can get in there because the person is listening to
> the output of ecasound and playing or singing with it.

It should specifically work when using a live signal as base!
Let's take a simple multitrack setup:

ecasound -a:mon -i:track1.wav -o:/dev/dsp \
         -a:rec -i:/dev/dsp -o:track2.wav

Goal of the multitrack-sync code is to make sure that the first sample
written to track2.wav was recorded from /dev/dsp at the same time as the
first sample from track1.wav came out from your soundcard's output.

It's not critical that the two /dev/dsp instances are started in sync (*).
All that matters is that track1.wav and track2.wav are synced.

But of course, as I said in my earlier post, ecasound's mt-sync code is
not perfect, and there's room for improvement. I'd be interested in
hearing about how the current CVS-version of ecasound works for multitrack
recording. I've recently made two specific changes to the sync-code (one
in 2.1dev0, and another in the yet-to-be-released 2.1dev2). I've done
quite a lot of recording with these, and with good results. If you make
test recordings, please take a note of the following line printed by the
ecasound engine:

(eca-engine) sync fix is xxx usecs.

On my machine, the sync-fix is usually between 20-50 usecs, which is not
much. One sample at 44100Hz takes ~23usec, so the sync-fix is just 1-2
samples. But the delay might be much longer on non-SMP machines.

In any case, without support from the hw-level, there's always a small
error (in modern computers a _lot_ happens during 20usecs). But for
practical (musical) purposes, delays below 1ms (1000usecs, ~44 samples)
are not noticable.

(*) On the other hand it _is_ important that the /dev/dsp instances
    run at the exactly same _speed_. It's because of this requirement
    that using multiple consumer soundcards to record +2 channels
    doesn't work (at least not reliably).

 Audio software for Linux!

-- To unsubscribe send message 'unsubscribe' in the body of the message to <>.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 16:54:15 EEST