Subject: Re: [ecasound] edi-15, smart selection of buffering params
From: S. Massy (theanaloguekid_AT_tak.net.dhis.org)
Date: Sat Oct 06 2001 - 16:02:59 EEST
On Fri, 05 Oct 2001, Kai Vehmanen <k_AT_eca.cx> wrote:
> I just commmitted the first implementation of edi-15 to the CVS. The
> initial results look good, although it turned out to be a much bigger
> project than I expected.
>
*clip*
>
> The three data sets are:
> - defaults values from ~/.ecasoundrc (separate defaults for
> 'nonrt', 'rt' and 'rtlowlatency' buffering modes)
This is something that I like a lot, the fact that one can tweak the
default for each scheme. By the way, am I right in thinking that this
obsoletes the old "default-to-*" config options?
> - override values given by user (command-line options, ECI/EIAM commands)
Do you mean that the command-line overrides the default or that the
default overrides the command-line? Only the former makes sense but I
ask just to be sure...
> - contents of the selected chainsetup
>
> When it's time to connect a chainsetup, ecasound does the following:
> - picks the optimal buffering mode for the chainsetup; this
> can be overridden with the new -B options (for instance '-B:nonrt')
> - takes the default values from the chosen bmode
> - overrides individual params (if any)
Shouldn't individually specified parameters always have precedence
over the defaults?
>
> And that's it! :) So for most peopple the new system should be completely
> transparent (no need to give -r, -b, -z:db, etc). At the same time there's
> even more flexibility for tuning performance params than with current
> stable ecasound release.
>
> One difficult step is still ahead: tuning the default values. At the
> moment, bmode specific defaults are:
>
> -B:nonrt
> -b:1024 -r:-1 -z:nodb -z:intbuf
I agree with that; at least it works fine for me.
> -B:rt
> -b:1024 -r -z:db -z:intbuf
Hrm... -r is a relatively "dangerous" option and can only be carried
out as root moreover: should it really be set by default without the
new user being aware of it?
> -B:rtlowlatency
> -b:256 -r -z:db -z:nointbuf
See below...
>
> In '-B:auto' mode (which is the default), 'nonrt' is selected if there are
> no realtime inputs or outputs (/dev/dsp, alsa, rtnull). If there are
> rt objects and current process has root priviledges, 'rtlowlatency' is
> selected. And in other cases it's 'rt'.
Here's my proposal:
- If no rt object: -b:1024 -z:nodb -r:-1 (same as nort above)
- one-way rt (simple playback/recording): -b:1024 -z:db -z:intbuf (-r)?
(like rt above)
- two-way rt (multitrack recording): -b:256 -z:db -z:nointbuf -r
(mostly like rtlowlatency above)
- pure rt (no disk i/o): -b:256 -z:nodb -z:nointbuf -r
The first scheme would be selected when no real-time objects are
present in the cs. The second would be selected when rt objects are
all either inputs or outputs. The third would be selected when
real-time are both inputs and outputs in the cs. An the last one would
be selected when there is no non-real-time objects in the cs.
>
> --
> http://www.eca.cx
> Audio software for Linux!
>
> --
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <ecasound-list-request_AT_wakkanet.fi>.
>
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Sat Oct 06 2001 - 15:58:46 EEST