Subject: Re: [linux-audio-dev] Plugin APIs (again)
From: David Olofson (david_AT_olofson.net)
Date: Tue Dec 10 2002 - 20:51:58 EET
On Tuesday 10 December 2002 07.56, Tim Hockin wrote:
> > > the RT engine - *unless* you decide on a number of VVIDs to
> > > allocate for each Channel of every plugin, right when they're
> > > instantiated.
> >
> > That sound most sensible. The instrument has to allocate voice
> > table space, so there is likly to be an internal (soft) limit
> > anyway.
>
> so this is the bit about VVIDs that bothers me - inefficient
> carving.
> * Must get more VVIDs than the instrument's polyphony
> * Must get enough so that if something else asks you can dole some
> out
> * Must get as few as possible to limit wastage.
Yes, exactly.
It wouldn't have been a problem if you could just assume that all
plugins handle the full 32 bit range of values, but that forces
plugins to do quite some work to find the voices. No big deal with a
few voices, but with 128 voices, most of which are in use, searching
starts to consume quite a lot of cycles...
> As was expressed - anyone who has a good idea how to work this out,
> speak up.
Indeed.
Anyone has a fast and simple hash/search solution? Operations needed:
* Mark object with a 32 bit value that someone gives you.
* Find previously marked object, using the same 32 bit value.
This is for up to 256 objects or so; the kind of polyphony one could
expect most synths to deal with. (I assume that with less than some
15-30 active voices, it's faster to just search the active voices,
provided they're in a linked list or something.)
Anyway, I think that would be a solution to the wrong problem.
We just need to address objects in a way that doesn't force us to
wait for someone to tell us which particular object we actually got.
We want the plugins to be able to do the allocations themselves, mark
the allocated objects, and then *quickly* find them again, when
referenced.
There *has* to be a better solution for this.
Hmm... IIRC, someone initially misunderstood my design and thought
the VVIDs were a common resource maintaned by the host.
Well, why not!?
Have the host maintain a single array of void pointers. A VVID would
be an index into this array. When someone wants to send events to
something with voices, it'll ask the host for a range of VVIDs. In
effect, it will be given those VVIDs, and a corresponding number of
actual entries in this array.
Now, when you send a VVID to a synth, the synth will take that as an
index into the host managed array, and so, it has some actual memory
assigned to this particular VVID, where it may put anything it wants.
How about an actual pointer to the allocated voice, or NULL when the
voice has been stolen, or if one couldn't be allocated? (For voice
stealing, you'd obviously want to mark the voice with the VVID or a
direct pointer to the VVID entry, so it can be updated as required.)
This is optional for plugins, of course. The VVID is now not just
Channel unique, but *host* unique, so you can still use the actual
value for mark/search.
Sounds better?
//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 -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
This archive was generated by hypermail 2b28 : Tue Dec 10 2002 - 21:03:07 EET