On Wednesday 18 December 2002 14.40, Steve Harris wrote:
On Wed, Dec 18, 2002 at 12:44:46 +0100, David Olofson
wrote:
I think
the host needs to own it because only the host knows
when it can be free'd again.
No, that would be senders, not hosts, I think. (Remember that
connected plugins send *directly* to each other's queues. The
host doesn't know what's going on.)
That said, the memory management definitely has to go through a
host service of some kind.
OK, I thought that the host was responsible for mashalling the
queues.
Only when you send events from different contexts to the same Queue.
There's normally no need for it otherwise.
The plugin must eb responsible for allocating the
space,
yes (unless it originates form the host, eg. host sequenced data).
The 'thing' that consumes the data needs to free it.
Yes. That's how the event structs are handled, so it would be sort of
nice if we could stick with that throughout the API.
Data blocks that will be need in an RT context (eg.
bulk
parameter pasing) can be allocated ahead of time.
How? A plugin can't know what it will send until it's in
process() - and then it's too late...
Well if its always sending 256 floats as a parameter it know its
going to be 256*sizeof(float) vytes long, so it can preallocate a
buffer that bit.
Yes, but how many such data blocks are needed per engine cycle? You
can't change a string or data control more than once per block,
unless there's an allocation system similar to that for events.
I guess the problem is that it doesn't know when
to reallocate a
new one.
That too.
This is definatly a difficult problem.
Well, that's RT memory management... *heh*
In the simple example case
of a UI sending a block of floats to the DSP code, its not a
problem, because the UI part is running non-RT anyway.
Yes, and that's one of the few cases where the host is marshalling
events. (It has to, because the event system in itself isn't thread
safe.) The host can either use an RT memory manager, or just restrict
things to one string/data block per engine cycle.
There is a feature for allocating audio buffers from the host.
Problem is that they're not of a hardcoded size, and they're
generally rather small; at most a few hundred bytes for low latency
hosts.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`--------------------------->
http://olofson.net/audiality -'
---
http://olofson.net ---
http://www.reologica.se ---