Re: Bug report: strange crash

On Thu, Apr 12, 2012 at 06:49:04PM +0300, Kai Vehmanen wrote:
> Hi,
> 
> On Wed, 11 Apr 2012, S. Massy wrote:
> 
> >- 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.
> 
> yes, I'm afraid this is expected. The stop/start procedure is slow
> (a lot of work is done before and after stopping).
Why is audio lost? Do the buffers get flushed?

> 
> >- 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.
> 
> Yes, this will help as you can reduce number of stop-starts (do many
> changes in one go).
Well, I'm embarrassed to say, I went back in the code and found out the
replace_effect logic is actually nested in a foreach loop, so the way I
ran the test, stop-sync/start would end up getting executed five times
in a row to bypass a whole chain, which can't be good any way you look
at it. I now moved those statements out of the loop, which makes much
better sense and actually works well. Sorry about the misleading report
there.

> 
> >- 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.
> 
> But I fear this is just not reliable. The 0.3/0.2 values depend on
> setup complexity, disk i/o speed (compared to amount of bandwidth
> needed by the setup), CPU speed, system load. So it'll be impossible
> to pick values that are reliable for everybody. :(
True on all counts.

> 
> In the end, I think the sane way forward is for me to add cop-bypass
> to the next ecasound version. Considering the overall effort, adding
> cop-bypass is a lot less work than doing complicated optimizations
> to the stop-start logic.
I think it would be a valuable addition to ecasound's feature-set,
whichever way you look at it. We would probably need a cop-is-bypassed
command as well, to provide a way to check.

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