Subject: Re: [ecasound] full-duplex sync
From: Kai Vehmanen (k_AT_eca.cx)
Date: Mon Oct 15 2001 - 21:40:05 EEST
On Mon, 15 Oct 2001, John Denker wrote:
>> 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
> 1d) If the foregoing is supposed to be a rationale for not supporting
> hardware sync, I don't understand. The presence of one feature does not
> prove that another feature is useless. Some hardware (including my
> hardware :-) does support exact hardware sync.
No, nothing like that! I was just giving reasons why the feature isn't
there already. Future is a a different thing. As always, ecasound
development goes forward. But it's also good to remember that I don't have
a monopoly on ecasound development. For instance you don't need my
permission to improve the sync-code. ;)
Also one good thing to to remember is that it was not until ALSA 0.9 that
there was an hw-sync API available for general purpose apps (ie. not tied
to any one specific soundcard). Ecasound has supported ALSA since 0.3.x so
this 0.9 stuff really is quite new. And actually, ALSA 0.9 isn't
officially released yet, so it's no wonder there aren't many apps using
its more advanced features. And add to this the fairly rapidly changing
nature of the ALSA APIs in the past (anyone remember the ALSA loopback
API?).
> 2) The fact that computers are fast (a lot happens in 20 microseconds)
> should make software-sync _more_ accurate, not less. So I don't understand
> this part of the argument, either.
This is true. A faster computer is better here. I was just reminding that
sometimes simple looking things are not so simple after all (two lines
of C code might look to be "pretty close", but in reality thousands
of machine instructions can be executed between those lines).
> 4) My team has a purpose, a very practical purpose, which requires highly
> accurate sync. We are looking at echoes. Shifting the return signal by
> one sample is noticeable, and shifting it by two or three samples (at
> 44100Hz) changes the result by 200%.
[...]
> Recommendation: When designing sync schemes, please be aware that the
> requirements are sometimes quite strict.
True, no doubt about it.
> Sub-recommendation: If/when hardware sync is available, it may be the
> easiest and best way to achieve excellent sync.
Also true. Anyway, I _am_ interested in adding hw-sync support to
ecasound. If it was easy, I'd probably add it right away, but there are
some real technical problems. One of the biggest ones is that ecasound's
audio inputs and outputs are treated as independent objects. For instance:
ecasound -a:mon -i file.wav -o alsa,default \
-a:rec -i alsa,default \
-a:rec2 -i alsa,somecard \
-a:rec,rec2 -o another.wav
Now if ALSA hw-sync API is used, only one of the devices belonging to a
sync-group needs to be started. But how does ecasound know which of the
above alsa devices are connected? To ecasound, the three alsa-objects are
completely separate. So we need to possibly add new options for specifying
which rt-devices are part of the same physical device, or some other
trickery to allow hw-sync support.
> Today I will download the latest ecasound and see if the recent mt-sync
> improvements meet our requirements.
I'm interested in hearing the results!
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Mon Oct 15 2001 - 21:37:24 EEST