Subject: Re: [ecasound] Bug in db system (Possible cause of sync problems)
From: S. Massy (theanaloguekid@tak.net.dhis.org)
Date: Wed Jun 27 2001 - 20:11:30 EEST
On Mon, 25 Jun 2001, Kai Vehmanen <k@eca.cx> wrote:
> 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.
Hm... but currently this is not quite transparent, ideally, it should
be the proxy's job to keep track of things so that Things are restored
correctly whenever a position change or other such even occurs. For
example, one of the actual problems, besides the ill-behaving fw/rw
commands, is when it comes to cs manipulations. So suppose I am
processing something (with db on, of course) and I find I suddenly
must perform a change in the setup that requires me to disconnect the
cs. When I reconnect the cs, processing will restart up to where the
proxy object had read in the file and _not_ up to what had been
processed resulting in a quite large skip in the file (about two
seconds for default dbsize).
>
> 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 ->
It currently works this way for linear processing, it's when it comes
to interactive manipulations that things start going amiss... And of
course, as double-buffering is most useful with real-time objects,
it's often in conditions where real-time manipulation is also
necessary.
> 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>.
>
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Wed Jun 27 2001 - 20:11:59 EEST