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

David Olofson david at olofson.net
Thu Dec 19 16:18:01 UTC 2002


On Thursday 19 December 2002 21.09, Steve Harris wrote:
> On Wed, Dec 18, 2002 at 07:12:29 +0100, David Olofson wrote:
> > 	* 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.
[...]
> Well, they would presumably keep the values from the previous data
> block.

Yes, but *where*?

A float control has the whole value in the event, and it's small and 
fixed size, so you can just copy it into your internal Control data 
array. Then you just throw the event struct away.

With raw data block events, OTOH, you get a block that could be of 
any size. *If* you could copy it somewhere, you'd just throw the 
event away, and the sender would officially own the block from then 
on.

Problem is that if you can't copy the data, you'll need the block 
until you get a new one.


We could either have an explicit "free_block()" action of some kind, 
or we could just do it implicitly like this:

	Cycle	Actions (S == sender, R == receiver)
	-----------------------------------------------------------
	1	S: Sends an event with block X to R.
		R: Gets the event and uses block X.
		(R owns block X.)

	2	S: Does nothing.
		R: Does whatever.
		(R owns block X.)

	3	S: Sends a new block Y to R.
		R: Gets block Y, and forgets about block X.
		(S now owns block X again.)
		(R owns block Y.)

	4	(Sender may now reuse block X.)


Note that this *does* work even if R decides to forward the block to 
a third plugin. Since blocks are read only, you may even "keep" the 
block and still pass it on. The only requirement is that when S sends 
a new block to replace it, the old block implicitly becomes property 
of S again, before the next cycle begins.

That is, you can't delay raw data blocks with this scheme, without 
copying the blocks. No major issue, though, as you're normally 
supposed to have your own blocks anyway, if you have raw data 
outputs. (You don't *need* to if you're not changing the data in the 
block - but we can just consider delaying a form of change.)


This might look a bit hairy, but the rules are quite simple:

	* When you get a new block, you must forget about
	  the old one before returning from process().

	* When you send a block of your own, it is property
	  of the receiver until the cycle after you've sent
	  a new block to the same control.


This will cause trouble in hosts that have sub-nets with smaller 
block size, if you're sending from within such a sub net. You'll 
expect a block to be back in the cycle after the one you in which you 
send the new block - but if the receiver has a larger block size, it 
won't have a chance to run before you want your block back!

Ok, such a host *could* deal with this, but there's another bunch of 
RT memory management issues...


No, I think this calls for either ever prevent RT memory management, 
or that blocks are handled by the host and marked with their "home 
address". That is, any plugin may set up one or more global memory 
block pools. The host's "free_block()" call will know where each 
block belongs.


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