[linux-audio-dev] XAP: Strings and Raw Data Controls

David Olofson david at olofson.net
Wed Dec 18 09:17:01 UTC 2002


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 ---



More information about the Linux-audio-dev mailing list