Subject: Re: [linux-audio-dev] more fundamental questions
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Tue May 22 2001 - 19:44:08 EEST
On Tue, May 22, 2001 at 10:54:04AM -0400, Paul Davis wrote:
>
> A few more items to ease your digestive processes :)
>
> 1) MP and shared memory
> -----------------------
> 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?
Well, the plugin knows wether its SP or MP at compile time, so you could
just define a macro that wraps the pointer value and uses it raw in the SP
case and adds it to the shared base address in the MP case. Not nice but
simple and fairly efficient.
> 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.
Is it neccesary to force them to be 1:1? Inplace may be more of an issue
though.
> 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 ...
Can't you force scheduler priority onto other processes with
sched_setscheduler(2)?
> 5) Defining the MP communication method
> ---------------------------------------
>
> Abramo used read/write to a pipe; Steve used kill(2).
There was no good reason for this, just that it was very easy to knock up,
without worrying about doing i/o to the child process.
It makes it harder to pass data to it, you'd have to set aside some shm or
something. If its just events you could just repurpose some of the little
used signals.
> 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
stdin seems like an obvious choice. You could use kill (or its modern
equivalent) back.
- Steve
This archive was generated by hypermail 2b28 : Thu May 24 2001 - 05:51:17 EEST