On Sat, Dec 31, 2005 at 08:03:06AM -0500, Paul Davis wrote:
On Sat, 2005-12-31 at 00:04 +0100, fons adriaensen
1. If things
have to be timed accurately, it seem logical to concentrate
this activity at one point. At least then the timing will be consistent,
you can impose priority rules in case of conflict, etc.
in a low latency *live* system, "timing" doesn't really exist outside of
the current period. there is no concept of "when" that exists beyond the
end of the current period.
In a live situation, yes. In that case there is no point at all to try
and deliver events with sub-cycle accuracy, except to a physical port.
For a soft-synth you don't even know _when_ in the cycle its audio code
will be called. So all events should be available at the start of the
cycle, and if you need sub-cycle precision or minimal jitter, be
well, clearly, yes. but the point of the ALSA
abilities (as distinct from its routing abilities) is really to schedule
stuff "far off" in the future. my claim is that live applications never
need scheduling beyond the of the end of the current period. as a
result, for this class of applications, most of the ALSA sequencer's
capabilities are redundant, which is compounded because it currently has
no way of providing sufficiently accurate scheduling (to be fair, at the
moment neither does user space).
Whatever system becomes available to user space can be used by ALSA as
well, so ALSA will never be in a worse situation than any app.
Even in a live context you may want to schedule e.g. MTC events in the
near (but more than 1 cycle ahead) future. Having a central scheduler
you could arrange for them to have priority over anything else. This
would be quite difficult to do when for example one app is scheduling
its MTC events and anothor produces a stream of control events going
to the same port.