Subject: Re: [linux-audio-dev] XAP: Strings and Raw Data Controls
From: David Olofson (david_AT_olofson.net)
Date: Wed Dec 18 2002 - 13:44:46 EET
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 ---
This archive was generated by hypermail 2b28 : Wed Dec 18 2002 - 13:49:24 EET