Re: [linux-audio-dev] laaga implementation news bite

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] laaga implementation news bite
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Jun 11 2001 - 16:57:48 EEST


>Ok, thats code I understand. How is this different from the GLAME
>approach which does (same scope as your example):
>
> client (within a library, wrapping up a callback like operation)
> read(inputportfd, &control, 4);
> switch (control->event) {
> case ProcessEvent:
> registered_process_func (control->buffer ...);
> break;
> ...
> }
> write(outputportfd, &control, 4);

its not different at all as long as the "connections" represented
by inputportfd and outputportfd remain static.

but what happens when this particular client is now supposed to run
later in the graph? how does inputportfd and outputportfd get reset to
point to the correct "next" client ?

>Also neither with sync. nor async. operation reconfiguring of the graph
>takes any work - it happens automatically. So to show how the manager
>client whould ensure sync. operation look at the following graph:
>
> buffer gen 1 \
> buffer gen 2 - manager - worker - worker - consumer
> ... \ ----- < -----------------/
>
>so the manager "passes" one buffer at a time (to every output it has)
>and passes more buffers only after the buffers have re-arrived [note

ok, so in this model, you are running synchronously w.r.t. the audio
interface. but this doesn't address the problem i mentioned above.

suppose the current execution order (based on the flow graph) looks like:
        
        worker1
        worker2
        worker3
        worker4

now the user reconfigures the graph by adding/removing some connections,
and the order is now:

        worker3
        worker1
        worker2
        worker4

how you do you propose to reconfigure the execution of a set of
external processes to reflect the new order? its easy to do this with
internal clients (plugins), but not with external ones, since they
each need (1) to know who is next and (2) to have some way of
notifying that client that its "their turn" ...

if you use read/write then as far as i can see this would mean that
every client has to have an fd connected to every other client, and/or
would have to reconfigure its fd's every time the graph changes. true?

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jun 11 2001 - 18:19:09 EEST