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

David Olofson david at olofson.net
Wed Dec 18 06:51:01 UTC 2002


On Wednesday 18 December 2002 10.45, Steve Harris wrote:
> On Wed, Dec 18, 2002 at 12:50:00 +0100, David Olofson wrote:
> > > I'm leaning towards the "strings in raw data blocks" approach,
> > > despite the little strlen() inconveniency for senders. Mostly
> > > because it's one control data type less to care about, without
> > > loss of real functionality.
> >
> > On second thoughts, there might be something more to this: Who
> > *owns* the memory used for data to and from string/raw data
> > Controls? How is it allocated in the first place?
>
> That is a good point.
>
> 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.


> That does require the host to provide malloc functions though, but
> IIRC they are in there allready.

Yes, but those are generic, and don't have to be implemented RT safe, 
even in RT hosts. I think it might be nice if plugins can send 
strings of reasonable sizes without RT trouble in "simple" hosts. 
(We're talking about control *values*, really; not internal buffers 
or anything.)


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


> If an instrument knows that its not going to need to block again it
> cabn tell the host to free it,

Yes...


> if its going to be sent out then the
> host can track it

Track it, how? Eavesdrop?


> and free it if it consumes it itsself.

That's not a special case. The plugin would have to work like any 
plugin when publishing controls in the net.


> This is all quite a lot of work though. The alternative would be
> some sort of garbage collection (even just ref. counting would do)
> I guess.

Yeah... Still need RT allocation for sending, though. *heh*

OTOH, it might be useful to assume that strings and raw data blocks 
you get as control input are *read only*. Then you could send string 
events referencing statically or previously allocated data buffers. 

Rather than allocate memory from the host, you allocate a Memory 
Block Handle, which is passed to the receiving control. MBHes would 
have refcounting, so you can keep track of blocks sent.

If we state that the old MBH on a control becomes invalid when you 
receive a now one, we can reuse them without double buffering. That 
is, if you send one MBH to only one receiver, you're allowed to 
change the data and resend the same MBH, as long as you send this or 
another MBH to the original receiver.


Sounds a bit hairy, though.


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