Subject: Re: [ecasound] Bug in db system (Possible cause of sync problems)
From: Kai Vehmanen (k@eca.cx)
Date: Mon Jun 25 2001 - 03:52:56 EEST
On Thu, 7 Jun 2001, S. Massy wrote:
> Ok, I have found a bug in the double-buffering system that might also
> be the cause of the sync problems when doing multi-track recording
Although this looks a bit weird, it's actually feature of the current
-z:db implementation, not a real bug. And probably is not causing the sync
problems. Anyway...
> Kai mentioned some time ago. It would appear that the current
> position in the file is the one up to which the stream has been
> buffered and not up to what has been processed, this triggers an
> inconsistency between the current position in the cs and the current
> position in the file. But an example will speak more clearly:
Currently only ecasound's engine is aware of the -z:db buffering. Ie.
engine accesses the audio objects through buffering proxy objects ('engine
-> db-proxy-input -> real-input'). Other parts of ecasound only see the
real objects ('user-interface -> real-input').
So checking the file position during processing will show where the
db-proxy-input is going at the moment. The engine however is still working
on data read a few seconds earlier.
The idea behind this design is that clients of the ecasound engine don't
need to know how disk buffering is implemented. They just enable the -z:db
flag and pass a normal chainsetup. But I might reimplement this part of
the -z:db in the future (.. in all cases 'someobj -> db-proxy ->
real-object'). The biggest problem with spreading proxy-object all over
the system is handling de-proxying (ie. when saving a chainsetup, you want
to save the real objects, not the proxies). And also, you want to avoid
proxy objects wrapped in other proxies... :)
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Mon Jun 25 2001 - 03:59:13 EEST