On Thu, Nov 3, 2011 at 9:22 AM, Harry van Haaren <harryhaaren@email-addr-hidden> wrote:
> On Wed, Nov 2, 2011 at 5:09 PM, Iain Duncan <iainduncanlists@email-addr-hidden>
> wrote:
>>
>> I'm hoping to arrive at some sort of design that ultimately lets the
>> engine act as an audio server with multiple user interface clients, possibly
>> not even on the same machines
>
> Did you concider using OSC as an "abstraction layer" between your GUI &
> Engine? Spares quite a lot of nasty shared-mem tricks, and RCU, well.. is
> suppose you could have the editing commands sent to engine, or else run the
> algo on the GUI side, and update the sequence in the engine.
no, using a protocol like OSC doesn't solve the basic problem: making
changes to data structures used by the RT code when those changes
can't be done with RT constraints (e.g. memory allocation). you still
need some code that runs outside RT constraints to modify the data
before giving the new version to the RT code to use.
--p
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Nov 3 16:15:01 2011
This archive was generated by hypermail 2.1.8 : Thu Nov 03 2011 - 16:15:02 EET