[gmpi] Re: Decision Time: 7.1.1
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 9 Jun 2003 22:22:22 +0200
On Monday 09 June 2003 21.57, Steve Harris wrote:
> On Mon, Jun 09, 2003 at 09:19:35 +0200, David Olofson wrote:
> > I like a), but I *think* c) could enable some performance
> > improvement often enough to motivate the extra host side
> > complexity. (I assume it's little more than a hint and hardwired
> > code on the plugin side.)
> >
> > So, unless I'm proven wrong, I vote for c).
>
> Will the possible performace benefit from c) outweight the cost of
> swizzling for when its not the same in adjacent plugins?
I doubt it... That's why your average plugin should not use
interleaved buffers.
The problem is that there is a conflict between the situations where
interleaved buffers make sense from a connection POV (like
"horizontal" mixer modules), and the situations where it allows
internal optimizations in plugins.
> If
> interleaved processing is unusual then the chances of having two
> adjacent interleaved plugins is low, so why not just swizzle inside
> the plugin?
Exactly. Faster than having the host do it, and it allows a plugin to
turn 5.1 (6 mono streams) into 4.2, 2.2.2 or whatever (one
interleaved stream for each figure) - something I can't imagine the
host could do without a sigificanty more complicated API than what (I
think) was intended for c).
> It would be reasonably simple for someone to test wether
> interleaved buffers can be more efficient, it seems highly unlikly
> to me. I suspect they are are only more efficient when the number
> of channels is a multiple of four and the number of samples is a
> small, non-mutiple of four.
>
> As soon as you have the possibility of unconnected inputs or
> outputs it becomes hard to optimise in the interleaved case, for
> mono buffers its trivial.
Right. It's only a win when it fits *perfectly*. In all other cases,
it means extra work.
So, unless I'm forgetting something, it seems like I'm (back) on the
a) side of the fence... Mono buffers only.
//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://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
