Subject: Re: [ecasound] edi-15, smart selection of buffering params
From: Kai Vehmanen (k_AT_eca.cx)
Date: Sat Oct 06 2001 - 18:21:32 EEST
On Sat, 6 Oct 2001, S. Massy wrote:
>> - 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?
Yep, all default-* options concerning buffering mode parameters are
gone.
>> - 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.
> Shouldn't individually specified parameters always have precedence
> over the defaults?
Yes, see above.
>> -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.
> 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
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.
My own reasoning behind rt and rtlowlatency modes was:
- -z:db is always necessary when nonrt and rt objects are mixed
- in almost all use-cases with rt-objects, low-latency (-b:some_low_number
-z:nointbuf) is preferable
- without raised priority (-r, rt-scheduling), -z:nointbuf performs
badly
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. ;)
-- 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>.
This archive was generated by hypermail 2b28 : Sat Oct 06 2001 - 18:18:55 EEST