[LAD] opinions wanted on a couple of architecture questions

Iain Duncan iainduncanlists at gmail.com
Fri Dec 9 19:54:10 UTC 2011


As I slowly figure out audio architecture, I've gotten to here:

main()
  - sets up jack, instantiates and Engine class and a Controller class

Engine
- the engine is passed to the jack audio callback, and has a .tick() to
calculate audio
- engine will receive messages over ToEngineQueue ( with a ringbuffer )
- engine will send messages back to controller over a second queue,
ToControllerQueue

Controller
- started in main thread
- will handle all input and output and instantiate any guis
- sends messages to engine over queue
- receives messages from engine over the ToControllerQueue

Message
- struct for passing messages, holds simple numbers, keeping individual
messages of known size for now

I've seen a few ways now in tutorials of handling some things and would
love opinions.

- Should the ToEnqineQueue be a part of Engine? ie, do we pass messages to
engine
 with engine->newMessage( msg );
- or should the queue's be instantiated in main and should Engine and
Controller each get pointers to the queues?
- I think the stk examples do the former and SuperCollider the second

- is it a bad idea to have both engine and controller need pointers to each
other?
- is this an example of an undesired circular dependency?
- is avoiding that by having them each only depend on Queue and Message a
good plan?
- or should I avoid it by using an ABC for MessageReceivingComponent and
allow them each to have pointers
of type MessageReceivingComponent?

- how should one handle memory management of the messages? Is it ok for
Engine to allocate memory for new
messages and have them destroyed on receipt,
- or should I have queue delete the memory and return by value when
messages are fetched?
- what is the crustimony proceedcake for allocated memory from an engine?

thanks to anyone who feels like they have the time to answer these!
iain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20111209/68116bb3/attachment.html>


More information about the Linux-audio-dev mailing list