On Wednesday 18 December 2002 16.21, Steve Harris wrote:
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.
I can think of situations where you might want a few kB, eg. FFT
plugins.
Yes...
Let's assume a few things:
* Raw data blocks belong to the sender.
* Received raw data blocks are only valid until the
the plugin returns from process().
* Senders can figure out at init time how many
and how big data blocks they need.
That would make things quite trivial, as you can just assume that the
blocks you send are yours to use again for the next block. However,
I'm not sure how useful such a scheme is. It's sort of weird that you
end up with undefined "value" on some controls, unless they get input
first thing every block. *heh*
Alternatively, mark the block with an "owner ID", so they can be sent
back to the right place upon deallocation, as suggested by Tim
Goetze. I rather like that idea, since it allows receivers to just
keep the last block until a new one arrives.
//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 ---