Subject: Re: [ecasound] Synchro saga: some background -RESOLVED (I think)
From: Kai Vehmanen (firstname.lastname@example.org)
Date: Tue Mar 20 2001 - 10:44:16 EET
On Mon, 19 Mar 2001, Roy Cutler wrote:
>> Doh, I meant to write -z:nointbuf .. :)
> This did it. I don't know why but you probably do. What would be the
> particular circumstances that make this necessary? Anyway, thank you all for
Very good to hear that it helped. :) Anyway, maybe it's time to make
-z:nointbuf the default behaviour. At least in theory, -z:intbuf should
not trigger the synchro problems. But as it happens, it there are problems
in the driver-level (usually problem lies in the OSS trigger code),
-z:nointbuf will produce a sensible worse-case behaviour.
Just to refresh your memory, -z:intbuf and -z:nointbuf are used to control
whether realtime audio objects (~= soundcards) are allowed to maximize the
use of internal buffering. The default is -z:intbuf, which improves
streaming performance (bigger buffers). But by looking at recent bug
reports, I think it's better to change the default behaviour.
As for ecasound's multitrack synchronation, the basic system is simple:
1. preload outputs with data (=> we are ready to go)
2. all outputs are triggered and the exact trigger time is recorded
3. ecasound tries to make sure that the first bytes written to disk
are those that were recorded precisely at output trigger time
-- http://www.eca.cx Audio software for Linux!
-- To unsubscribe send message 'unsubscribe' in the body of the message to <email@example.com>.
This archive was generated by hypermail 2b28 : Tue Mar 20 2001 - 10:55:25 EET