Re: [linux-audio-dev] Audio/Midi system - RT prios..

From: fons adriaensen <fons.adriaensen@email-addr-hidden>
Date: Sat Dec 31 2005 - 18:01:06 EET

On Sat, Dec 31, 2005 at 08:03:06AM -0500, Paul Davis wrote:
> On Sat, 2005-12-31 at 00:04 +0100, fons adriaensen wrote:

> > 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
timetagged.

> well, clearly, yes. but the point of the ALSA sequencer's queuing
> 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.

-- 
FA
Received on Sat Dec 31 20:15:06 2005

This archive was generated by hypermail 2.1.8 : Sat Dec 31 2005 - 20:15:06 EET