Subject: Re: [ecasound] sync-related issues
From: Kai Vehmanen (k_AT_eca.cx)
Date: Tue Nov 06 2001 - 17:49:03 EET
On Tue, 6 Nov 2001, John Denker wrote:
> 1) Using ecasound v2.1dev2 we observe that there is "usually" exact sync,
> but in about 5% of the runs it is off by one sample. That's 22
> microseconds (when using 44100 Hz sampling).
Are you running as root (-> ecasound runs with sched_fifo rt-scheduling)?
An unwanted scheduler invocation is one possible explanation for the
occasional sync errors you are seeing (ie. kernel switches to another
process just when ecasound is starting up processing). This can be
avoided by running as root.
> <digression topic=latency>
> 2) Using ecasound v2.1dev2 we observe a 2-second latency when the record
> thread starts up. Apparently it is prefilling some internal buffers. We
This is the disk-i/o subsystem. Double-buffering is necessary to avoid
propagation of disk i/o latency peaks to engine's operation. This is
critical for robust performance (we can buffer non-rt devices like disks
but not rt-devices like soundcards). But you can disable this feature with
-z:nodb.
> can't tolerate that kind of latency. We could tolerate a millisecond or
> so, but we don't understand why even that should be necessary. The "sync
> fix" as reported by ecasound is observed to be 10, 11, or 12 microseconds.
> We don't understand why the latency should be 10^5 times larger than this.
The -z:db prefilling happens before processing is started, so it doesn't
affect the sync-fix phase.
> Latency was OK in version 2.0 -- but it's alarming when the new version
> works worse than the old version. Is there any way to make this problem go
> away?
In 2.0, -z:nodb was the default setting, so there was no prefill phase by
default.
> Comments and questions:
> a) We would be delighted to have a sound-processing program with support
> for hardware sync. We looked at ardour but it doesn't appear to be ready
> for prime time yet. Is there any chance of getting ecasound to do this?
> Is anybody working on this?
> b) Is there any chance of getting super-good software sync?
While I intend to work on both implementing hardware sync support and fine
tuning the current sw-sync code, I would be lying if said when. And I
can't speak for others who possibly might work on this. For my living, I
currently work on multiple commercial projects (unrelated to ecasound) and
am trying to finish my uni studies. So ecasound development is very
bursty. Nothing might happen for weeks (or even months), and then when I
have the time, I can implement numerous big changes during a few intense
coding days. As can be seen from ecasound-list archives, this has been
going on for quite a while.
So your choices are:
1) wait that someone implements (a) or (b) (with the risk that
nobody ever implements it)
2) if you have people who know C++
- write a hacked version of ecasound with hw-sync
support for your purposes (this is probably faster than
writing generic hw-sync support)
- like above, but just fix the sw-sync
- help ardour development so it fits your needs
3) if you have the resources, hire someone to do (2)
I've been in the same situation myself a few times in commercial projects
(or projects with deadlines in general). You have an open-source
component, which is almost what you need, but still not close enough. So
you end up with the above options. I think I've used all the above 1+2+3
approaches at some point.
-- 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 : Tue Nov 06 2001 - 17:42:50 EET