Hi,
On Mon, 19 Jan 2009, Linux Media wrote:
>> What Ecasound does is to implement is a "catch JACK's current position"
>> algorithm that issues new read-ahead requests to all file objects until
>> they eventually catch up. Depending on your disk i/o capacity and the number
>> of files in your setup, this may take long (even multiple seconds).
>
> Is it possible that this is aggravated by using double buffering?
>
> I know that if I do -z:db, that I get delays when doing "fw num" or "rw
> num", but with -z:nodb, the repositioning happens immediately.
yes, this is directly related to -z:db. But unfortunately -z:nodb does not
fix the problem, but instead moves the problem forward, and exposes the
disk i/o delays directly to the JACK client graph (i.e. breaks one of the
core design rules for JACK clients). In most cases your client will most
probably get kicked out of the JACK system if you use -z:nodb due to
ecasound failing to meet the real-time requirements.
A better solution is to decrease the amount of double-buffering. This way
you can speed up the seeks a bit by sacrificing some of the real-time
safetiness. Ecasound's defaults are fairly converservative, so on most
modern systems one can safely use smaller values.
-- ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Ecasound-list mailing list Ecasound-list@email-addr-hidden https://lists.sourceforge.net/lists/listinfo/ecasound-listReceived on Tue Jan 20 00:15:04 2009
This archive was generated by hypermail 2.1.8 : Tue Jan 20 2009 - 00:15:04 EET