Subject: [linux-audio-dev] more fundamental questions
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue May 22 2001 - 17:54:04 EEST
A few more items to ease your digestive processes :)
1) MP and shared memory
-----------------------
If we are going to support a multi-process model with LAAGA,
there needs to be a way to create buffers and Ports and probably other
objects in shared memory. This is difficult to do transparently,
because the shared memory area will likely be mapped to a different
base address in each process. I know that shmat can try to force the
address, but there's no guarantee that it will work. That means that
using straightforward pointers such as
struct Port {
sample_t *buffer;
...
};
won't work, since the value of the `buffer' pointer will be specific
to the process that creates the buffer. The same will apply even to
a pointer to a Port.
Since supporting MP seems like an excellent idea, we need a solution
to this. I can think of a few, but they seem a little ugly. Any ideas?
2) MP and shared memory, part II
--------------------------------
Its easy to define a "proxy" for the MP case so that the engine can
treat both in-process and out-of-process clients in the same way when
its executing the "process()" callback on each client.
However, every other part of the API for a "client/plugin/whatever"
would need to be represented by an RPC. For example, when a client
requests/registers a new Port, the engine will need to make callbacks
to the client. These callbacks will eventually need to result in some
IPC to the actual process in which the client lives. This needs to be
handled by the API we define, and not left up to each client.
3) Typed Ports
--------------
Although right now we are 100% focused on ports for handling PCM audio
data, I want to keep our eyes on the idea that we need to offer easy
ways to extend the Port types. My proposal for this is fairly simple.
First, we use strings to name the Port types, not integer values. This
way, people can invent arbitrary port types. Second, all such
"non-builtin type" Ports can only be connected 1:1. Thirdly, output
ports of such types provide their own sized buffer. Fourthly, and
rather obviously, you cannot connect a Port of type A to a Port of
type B.
If we do this, then I think that allowing port types like "MIDI",
"Ambisonic Data", "Positional 3D Audio", "Whatever" will be extremely
easy to work into the proposal I made yesterday. The buffer's will be
handled with zero-copy methods, and nobody but the two connected
Ports (and their owners) will care what is in them.
The use of named types costs us basically nothing, since the only time
we really need to check them is from outside the audio thread.
4) Ensuring correct scheduling
------------------------------
In the MP case, each client must ensure that its audio thread is
running SCHED_FIFO (or maybe just SCHED_RR, not sure about this
yet). How do we do this easily? Do we care enough to try to enforce
it? Presumably, its important that they run at the appropriate
priority level within SCHED_FIFO as well ...
5) Defining the MP communication method
---------------------------------------
Abramo used read/write to a pipe; Steve used kill(2).
We need to define which method is used; I don't care. If we use a
pipe, then we need to define the fd number that will be used by the
client to listen for process() "requests" and notify that they are
done. Its not quite clear to me how to set this up correctly. For that
reason, the kill() method seems slightly easier, but it has a real
cost: signal handlers can only safely use async functions. On the
other hand, we can use sigwait() to catch the signal and then things
are OK. This is slightly trickier to set up, but not much.
Comments?
--p
This archive was generated by hypermail 2b28 : Tue May 22 2001 - 18:22:41 EEST