>> - defaults values from ~/.ecasoundrc (separate defaults for
>> 'nonrt', 'rt' and 'rtlowlatency' buffering modes)
> 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...

It's the one that makes sense. :) The chainsetup parser maintains a
set of override values. All command-lines options and iamode commands that
affect buffering paramers modify this override set of values. If override
set contains any settings, they override ~/.ecasoundrc defaults.

>> -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?

There are certain things that make running ecasound as root dangerous. But
-r is not one of them. It makes no difference whether you specify -r or
not. So running ecasound as root with or without -r is just as dangerous.
It's true that in some cases it might a problem that ecasound raises its
priority, but as experience has shown, there's no other way to get
acceptable realtime performance.

First we can combine the pure-rt and two-way-rt modes. The -z:db system is
completely transparent for realtime objects (no performance overhead),
so adding -z:db doesn't affect pure-rt setups.

But then comes the difficult part - the two rt-modes. One problematic case
(which, btw, origianlly led me to add -z:nointbuf) is when ecasound
streams from a file, has some MIDI-cc controlled effects and then a
soundcard output. With your modes, one-way-rt would be selected. And this
would be far from optimal (very long latency for MIDI-control). The
correct mode would be two-way-rt.

The problem is that it's very difficult to identify these cases. Searching
for MIDI-controllers is not enough. User could for instance use some
ECI-app to control the effect params in realtime. Again the two-way-rt
mode would be needed.

And the solution: always try to get -r, if that fails, fall back to
parameters that work without -r (even if sacrificing low-latency).

Hmm, but your one-way-rt mode is an important case to consider. In my
current design, simple playback as root would run in rtlowlatency mode.
And this is one of the cases where lowlatency is of no use. Let's see, how
about a rtreliable (or rthugelatency :)) mode, with the following
criteria:
- engine is started with interactive-mode disabled
(=doesn't respond to any outside control, a batch-type
mode), OR
- a) there are no chain operators in any of the chains
(far from optimal, but at least we can be certain
that long latency times won't be a problem) AND
- b) operation is one-way, ie. there are either
rt-inputs or rt-outputs but not both

I can't come up with any cases where this would fail, although there might
be room for improvement (...more cases where latency is not a problem).

PS This has turned out to be quite a fascinating problem area! :)
PPS One nice feature of this new bufparam selection system is
that it's completely dynamic. Already in older ecasound versions,
if you have a chainsetup connected and you add new objects to it,
ecasound automatically disconnects the chainsetup,
adds the objects and then reconnects. With the new system,
before reconnecting ecasound will automatically optimize all
buffering parameters for the new chainsetup! Not extremely
useful, but nice addition to the feature list. ;)