Re: Bug report: strange crash

Hello,

On Thu, Apr 12, 2012 at 12:10:31AM +0300, Kai Vehmanen wrote:
> Hi,
> 
> On Wed, 11 Apr 2012, Kai Vehmanen wrote:
> 
> >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".
> 
> ... but now there is! I just pushed a patch to add "stop-sync"
> command [1] I also pushed some other fixes [2] that make the
> automatic stop-edit-restart sequence more reliable. Now, even
> without using the new "stop-sync" command, I cannot cause your test
> setup to fail anymore.
> 
> I'm sure there are still bugs in this area, but this at least fixes
> the more urgent ones. And "stop-sync" will definitely be a useful
> tool for syncing with ecasound state.
> 
> [1+2] in git:
> a069772... Added 'stop-sync' command
> 408f38e... Add is_started() to eca-engine and eca-control
Okay, so I pulled and experimented... Since I'm no programmer of the
year, you'll have to bear with me describing the symptoms rather than
the causes.
- Implementing stop/replace_effect_logic/start:
  It no longer crashes but is slow even for one effect, and can take
  upwards of ten seconds to bypass or restore a whole chain of effects. 
  A random amount of audio gets chopped off.
- Implementing stop-sync/replace_effect_logic/start:
  No crash, bypassing one effect (IOW cop-remove/cop-add) is pretty
  instantaneous, but bypassing several can take up to two seconds, which
  is long but much less than the previous instance. When bypassing one
  effect, there seems to be no obvious audio lost, but a random amount
  of audio gets chopped off when bypassing several effects in one go.
- Current method stop/sleep/replace_effect_logic/sleep/start with
  ecasound 2.8.1:
  We sleep a total of 0.3 seconds, 0.2 between stopping and replacing
  the effects. No audio lost, no significant delay, no matter how many
  effects are being replaced.

My guess is that something in the new code is causing slow-downs and
audio loss becoming really bad as the number of cop operations mounts
up. For some reason stop-sync seems to mitigate this effect somewhat,
but from an end-user standpoint, the old behaviour is actually more
pleasant/reliable. Could it be the is_started() logic causing this
mischief?

One word of warning, I compared behaviour between latest git master and
2.8.1, so it could be that this problem was introduced earlier. If you
like, I can go back a few commits and try again tomorrow.

Cheers,
S.M.

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Ecasound-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ecasound-list