Hi,
On Mon, 9 Apr 2012, S. Massy wrote:
>> ... now the bad news is that this logic starts to fail when fed a
>> lot of commands (from an app, versus a live person typing commands
>
> Right, so what we did in the mean-time is stop the engine to do the
> bypass and restart afterwards: it gives a hickup on the audio, but at
> least it works. An interesting aspect, though, is that there still seems
> to be some timing issue, even when stopping, because cop-remove'ing to
> close to stopping would still occasionally trigger the bug. So what we
yes, this a gap in the available API/command-set.
Problem with "stop" is that it's an asynchronous method. Calling "stop"
sends a request to the engine to stop, but it does not guarantee that when
the call to "stop" returns, that the engine has stopped. And there's no
synchronous variant available at the moment -- i.e.
"stop-and-do-not-return-until-engine-has-actually stopped".
As the interactive mode is essentially syncrhonous (there are no async
messages from ecasound to application), I think the correct fix is to make
"stop" synchronous.
This affects only a very small set of commands, and majority are already
synchronous (the requested action is completed when the command returns).
> do now is:
> - stop
> - sleep some
> - perform the operation
> - sleep some more
> - start
>
> Right now, we're sleeping about 0.02s before and 0.01s after, which we
> very heuristically determined to be safe values.
The first sleep is due to the above, but the second one is a bit
suspicious. There should not be any need to have a sleep before start. If
this causes errors, then the cause is probably something else.
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Thu Apr 12 00:15:03 2012
This archive was generated by hypermail 2.1.8 : Thu Apr 12 2012 - 00:15:04 EEST