[linux-audio-dev] Audio synchronization, MIDI API

[Fons Adriaensen]

On Sun, Aug 15, 2004 at 01:58:49PM +0200, Benno Senoner wrote:

> >If you absolutly have to have multiple machines doing i/o then you will
> >need some complicated resampling stuff. Fons has been working on it, to
> >allow soft-sync between 2 jack systems, but I've not tried it yet.

Between a JACK system and a second ALSA card, more exactly. It works
with some cards, but for example not yet with USB, where the timing of
the ALSA buffer ready events is very irregular. 
 
> Interesting, any online pointers ?

Not yet, unfinished work, waiting for more time.

> Fons what's your take on the sample skipping/duplicating ?

Depends on the program material. It works very well for speech
and 'background quality' music. I don't think it will work well
in the general case. But there are other possibilities.

If the resample rate is close to one, eg. 1 +/- 1-e4 (most cards
I guess will achieve that (?)), you can save a lot of the work
by only resampling part of the time.

For example instead of resampling 10000 samples to 10001, you could
copy 9000 samples and then resample 1000 to 1001. This allows the
resampling code to handle at least 10x more channels for the same,
CPU load.

It will introduce a bit of 'vibrato' on your signal, in this case
with an amplitude of 1/59 of a semitone, which is probably harmless.

An efficient implementation would be a fixed N to N-1 or N+1
resampler (that can be optimised), and kick this in 'on demand',
whenever the desync approaches half a sample. The extreme case
of this is of course 1 to 0 or 2, i.e. skipping or inserting
samples. I think it could work even with relatively small N,
say 256, if you ensure it is not used with a regular period,
but a bit randomized. With is N, and a maximum relative error
of 1-e4, you work only 2.56% of the time.

The really hard part is estimating the resample ratio. With the
current interfaces (no HW timestamps on sample buffers), a lot
of filtering is required and that makes the estimation very slow.
Even If ALSA would provide a timestamp on the interrupt handler
(and a virtual one when USB is reformatted to 2^N buffers) that
would help a lot.

As a result you either have to accept a lot of extra latency to
allow for the speed difference before the resample ratio is
known, OR accept to wait a few seconds (probably not a real
problem), OR have some a-priori knowledge of the resample ratio
to 'prime' the state of the DLL.


-- 
Fons