Subject: Re: [linux-audio-dev] laaga implementation news bite
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Jun 11 2001 - 21:02:15 EEST
>> 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 ?
>
>You have the same "race" with your approach - just doing the forward
>from the client does not work if f.i. the supposed to be next client
>is either re-routed or deleted during operation.
its not the race that i'm concerned about. thats dealt with quite
separately. the problem is redefining the execution order ... read on ...
>where remove connection would just close the fd's (so pending
>reads/writes will just return with an error which the above
>code may need to handle explicitly) and add connection would
>instantiate a new pipe (and you need to signal the connected
>components to update their knowledge about their connections).
and pass them the file descriptors as well, since they can't open the
pipe by themselves (they don't know about each other at that point).
ok, it will work, but i must say that it seems really quite ugly and
unappealing to me. the semantics of signal(2) are much closer to what
we're really trying to do here than those of read(2)/write(2). i
really don't see a reason to prefer the r/w approach when it involves
so much more work to establish a new port connection ...
what does anybody else think?
>Note that you cannot avoid "loosing" frames during such operation
>(obviously - a worker reorder is not an atomic operation - making
>it atomic would involve "stalling" execution and such probably
>lead to other problems as well).
agreed. i have long been an advocate of this position. sometimes, you
may avoid an audio glitch due to good luck and excellent timing, but
there's no guarantee of it.
>> 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?
>
>You would have to, but so do you (update your graph).
actually, no, i don't, because there are no fd's used to implement the
graph. in essence, we just sort an array of PIDs to reflect the graph
execution order. no fd passing, no pipe opening and closing, no
read/write stuff. just a simple signal, which is one of the fastest
syscalls we have.
--p
This archive was generated by hypermail 2b28 : Mon Jun 11 2001 - 22:08:05 EEST