Subject: Re: [ecasound] edi-15, smart selection of buffering params
From: S. Massy (theanaloguekid_AT_tak.net.dhis.org)
Date: Sun Oct 07 2001 - 23:39:03 EEST
On Sat, 06 Oct 2001, Kai Vehmanen <k_AT_eca.cx> wrote:
> 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.
I agree, it's no longer needed and the new scheme is better. However I propose
to reintroduce "default-schedpriority" and "default-double-buffer-size"
because right now if you specify -z:db or -r on the command-line they
default to zero.
>
> > 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.
Does it mean that -z:db can always be on but only kicks in when nonrt
objects are present? Now *that* is a good thing. :)
>
> 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.
Well, yes, but you can't foresee _everything_, you know. If someone uses
an ECI app to control ecasound then the app writer should be able to pick up
appropriate settings for his purpose.
There's so many situation in which one might use ecasound, it's hardly
possible to cover every use case...
>
> 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).
I see three types of ll setups:
- Full duplex (effect processing, for example)
- multi-track recording
- real-time controllers (midi, for example)
>
> 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).
Well, if it might help, here are some of the cases where I'd use this
rtreliable mode:
- simple playback (both interactive and non-interactive)
- simple recording (yet again, both interactive and non-interactive) (no cops)
- mixdown (I like to monitor the result in real-time while mixing down to a file)
By the way, some sort of error checking will need to be brought around,
because right now no warning message is issued if you give an invalid argument to
-B. for example, if you say -B:nort instead of -B:nonrt, the option is
just silently ignored.
>
> PS This has turned out to be quite a fascinating problem area! :)
Yes, it's a bit of a challenge...
> 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>.
>
-- 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 : Sun Oct 07 2001 - 23:34:50 EEST