Re: [PATCH] libecasoundc: retry eci_impl_fd_read() even if poll timeout (was: Re: eci_init() fails on MIPS)

Joel Roth <[email protected]> Tue, 4 Feb 2014 10:42:29 -1000
Newsgroups gmane.comp.audio.ecasound.general
Message-ID <20140204204229.GA12578@sprite>
Kai Vehmanen wrote:
> Indeed that seems to be the problem. For the initial reads, 
> eci_impl_read_return_value() is called with a short 5sec timeout and
> that apparently is too short on the MIPS test platform.
> 
> > So, a possible solution would be to retry the eci_impl_fd_read() even if the
> > timeout has expired. That part of the code is already run in a loop for, at
> > most, ECI_MAX_RESYNC_ATTEMPTS times, so there should be no risk in getting stuck
> > there.
> 
> That probably fixes it, but as the function is called sometimes with a 
> large timeout (30sec), combined with 9 retries, it'll cause quite long 
> delays to get notified of errors when something goes wrong.
> 
> Could you try bumping ECI_READ_TIMEOUT_MS to 15000 and see if that 
> helps...?

I wonder if a timeout could relate to a problem I
encountered. To set up Nama's effects database,
it sends Ecasound's *-register commands in series:
cop-register, preset-register, ladspa-register, etc.

One user observed that the replies were in the
wrong order when the commands were sent via NetECI
but only when his CPU was set to a power-saving
mode!

Cheers,

Joel

-- 
Joel Roth
  


------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Ecasound-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ecasound-list