Subject: Re: [linux-audio-dev] big picture, for a moment
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ma loka 11 1999 - 16:47:32 EDT
I think we need to step up a level or two, and try to clarify the big
picture again.
>From my perspective, I am now agreed that we should use an event
system similar to the one David has proposed. I agree that we should
use a constant frame/sample count argument to plugins, and let them
deal with events in any way they choose. I agree that we need 64bit
timestamps. External event sources (MIDI, audio cards, mice,
keyboards, X servers, etc.) will be handled by the semantic equivalent
of "sensor threads" that are partly autonomous, and partly dependent
on the engine thread. I think that David agrees that we will not use
shared memory directly to communicate with "clients" (other
processes), but instead will use "sensor threads" that will make
shared memory function like any other event source. Note: an
implementation may or may not use actual threads to implement this,
but the API will be defined so that threads *can* be used.
Where David and I currently disagree is the relationship between
plugins and event ports. I think of a plugin that is introduced to the
system coming into a world of many possible different event ports, and
having a clear idea of the kinds of things it wants to pay attention
to. Those may change as a result of user interaction, but I see the
plugin as "subscribing" to various event ports, and unsubscribing at
other times. Plugins may also be (un)subscribed to ports as a result
of user interaction and/or automation playback. The engine provides a
way to locate a port given its address, so that plugins can subscribe
to its ports of interest. Objects that generate events have no idea
who is subscribed to their ports. All events are timestamped using a
time base maintained by the engine, but usable without having to
preempt the engine thread (if it is indeed a distinct thread).
Next are some ideas that we have not talked about.
-------------------------------------------------
I propose removing the engine from any involvement in event
distribution. We can do this because event distribution does not
involve data copying. The engine is responsible for setting up
connections so that it can adequately grok the nets that the
interconnections create. But event sources simply post events to their
ports, and the port subscribers process the events. The engine is
responsible for marking the last event on any given port that should
be considered during a plugin's process() call. It is also responsible
for removing all events up to and including that last event at the
appropriate time, and doing appropriate games in memory with them.
Plugins and clients are different.
A plugin in a precompiled object file which can be dynamically linked
into any program that supports the engine-side of the API. A plugin
can subscribe to any event port known to the engine, register new
event ports, manage its own GUI (which will run in its own thread) and
consider itself closely coupled to the engine.
A client is a standalone program that uses the engine to route data,
or routes data for the engine. Clients do not have access to ordinary
event ports, but instead receive data streams and/or requests for data
from the engine. To make this point clearer, if you write an audio
sequencer as a *client* (i.e. it sends its audio data to an engine,
not directly to an audio device) it cannot receive events (say, GUI
changes or MIDI stuff) from the engine. If you write it as a *plugin*,
then you can.
However, even if the client case, you can still use the MCS library to
manage events within your own process space, and you can also host
plugins that use the API. This is the "anyone can write an audio
server" approach :) More significantly, by doing this, you can almost
certainly conveniently package the functionality of your application
in a format that can be a plugin.
Likewise, you might write an application that routes audio over a
network using some sensible protocol. Your program can be a client of
the engine, acting as one of its output destinations, and potentially
a destination for other programs that use the API as well. If you
write your program using the MCS API internally, you could probably
repackage it as a plugin as well.
Individual users of the MCS system would need to decide if they
preferred plugins or clients for certain purposes.
We have not talked about how to address ports. Strings are easy, but
speed daemons will prefer integer values formed via some scheme that
encodes the port's "name".
However, the description I have given above, I think that this is an
API that I can and would use for all my audio/MIDI programs.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST