Re: [LAD] Communicating between python UI and C++ engine for real time audio?

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Paul Davis <paul@...>
Cc: <linux-audio-dev@...>
Date: Saturday, November 5, 2011 - 10:49 pm

--20cf305b0a56d23af504b104a128
Content-Type: text/plain; charset=ISO-8859-1

> Basically one "RtQueue" instance can pass messages back and forth between

this approach requires that all your data structures can be

Just wondering if I can get a clarification, this is the internal
audio/sequence data for the engine that needs to be representable as POD?
The reason for this is so that when inserts happen the RT thread is not
dealing with memory management for a linked list? Am I correct in
understanding that it's the memory allocation part of creating new pointers
that needs to be avoided in the RT thread in case it blocks or gets stalled
by the OS?

Does this mean that if I can get away with some kind of data scheme for the
engine that is not dependent on the pointer management that it will be a
lot easier to update based on incoming queued messages?

thanks
Iain

--20cf305b0a56d23af504b104a128
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> Basically one "RtQueue" instance can pass messages back and =
forth between

its
fer.
inding which

this approach re=
quires that all your data structures can be
representable as POD (plain old data) and be effectively and easily
de/serialized from/to a bytestream.

this can be quite restrictive. linked lists, for example ...Just wondering if I can get a clarification, this is =
the internal audio/sequence data for the engine that needs to be representa=
ble as POD? The reason for this is so that when inserts happen the RT threa=
d is not dealing with memory management for a linked list? Am I correct in =
understanding that it's the memory allocation part of creating new poin=
ters that needs to be avoided in the RT thread in case it blocks or gets st=
alled by the OS?
Does this mean that if I can get away with some kind of=
data scheme for the engine that is not dependent on the pointer management=
that it will be a lot easier to update based on incoming queued messages?<=
/div>
thanksIain

--20cf305b0a56d23af504b104a128--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAD] Communicating between python UI and C++ engine for..., Iain Duncan, (Sat Nov 5, 10:49 pm)
Re: [LAD] Communicating between python UI and C++ engine for..., Gabriel M. Beddingfield, (Thu Nov 3, 2:05 am)
Re: [LAD] Communicating between python UI and C++ engine for..., Vytautas Jancauskas, (Thu Nov 3, 7:49 am)