Erratic behavior on jump via ECI with transport rolling

[Joel Roth-2]

Hello everyone,

For a while I have noticed that when I move the playback
head with IAM forward/rewind/setpos via ECI
(Audio::Ecasound), I encounter delays of two to ten seconds
or longer, depending on how complicated the chain setup is.
Delays are noticeable even with simple setups having no loop
devices.

The chain setups are okay: run directly from Ecasound
command mode I find no such delays on issuing jump commands.

The problems have persisted after I upgraded Ecasound to 2.4.6.1.

When polled during the delay, the engine_status shows 'stopped'.

A partial work-around I found is to stop the transport
before the jump and then to start the transport again.

When I issue jump commands while the transport is moving,
I also notice that sometimes the amount of the jump is
incorrect, (i.e. several minutes, or back to the beginning
instead of 30 seconds). The direction is right.

I'd appreciate any help in tracking down and or solving
these issues.

Also, I compiled Ecasound with debugging... is there a way to
turn it on and log the output when I working via ECI?

Regards,

--
Joel Roth












--
Joel Roth

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Kai Vehmanen]

Hi,

On Tue, 29 Apr 2008, Joel Roth wrote:
> For a while I have noticed that when I move the playback
> head with IAM forward/rewind/setpos via ECI
> (Audio::Ecasound), I encounter delays of two to ten seconds

you managed to solve this already, but a couple of comments still (which
might help to understand what happens inside the engine).

> The chain setups are okay: run directly from Ecasound
> command mode I find no such delays on issuing jump commands.
>
> The problems have persisted after I upgraded Ecasound to 2.4.6.1.
>
> When polled during the delay, the engine_status shows 'stopped'.
>
> A partial work-around I found is to stop the transport
> before the jump and then to start the transport again.

One thing to watch out for is that ECI commands are not executed in a
synchronous manner. So when you issue a seek ('seek to pos X'), you are in
fact sending a request to the engine, not actually performing action. So
when your ECI command returns, the engine may, or may not, have performed
the seek at that point. If you now check the current status with another
ECI command, it will return the actual status of the engine, which might
differ from your latest request.

The commands are also queued, so for instance submitting another seek
doesn't cancel the prior ones (but the order is of course kept).

--

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Joel Roth-2]

On Sun, May 18, 2008 at 05:11:48PM +0300, Kai Vehmanen wrote:

> Hi,
>
> On Tue, 29 Apr 2008, Joel Roth wrote:
>> For a while I have noticed that when I move the playback
>> head with IAM forward/rewind/setpos via ECI
>> (Audio::Ecasound), I encounter delays of two to ten seconds
>
> you managed to solve this already, but a couple of comments still (which  
> might help to understand what happens inside the engine).
>
>> The chain setups are okay: run directly from Ecasound
>> command mode I find no such delays on issuing jump commands.
>>
>> The problems have persisted after I upgraded Ecasound to 2.4.6.1.
>>
>> When polled during the delay, the engine_status shows 'stopped'.
>>
>> A partial work-around I found is to stop the transport
>> before the jump and then to start the transport again.
>
> One thing to watch out for is that ECI commands are not executed in a  
> synchronous manner. So when you issue a seek ('seek to pos X'), you are
> in fact sending a request to the engine, not actually performing action.
> So when your ECI command returns, the engine may, or may not, have
> performed the seek at that point. If you now check the current status
> with another ECI command, it will return the actual status of the engine,
> which might differ from your latest request.
>
> The commands are also queued, so for instance submitting another seek  
> doesn't cancel the prior ones (but the order is of course kept).

Thanks Kai, for explaining how ECI commands get executed.

I've traced my engine problems to off-by-one errors in my
cop-select operations that resulted in my attempting to
alter the state of non-existent chain operators.
The engine would stumble over these operations for
many seconds, during which time the engine would be
showing 'stopped' status.


--
Joel Roth


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list