[gmpi] Re: Topic 7: Audio packaging

  • From: Mike Berry <mberry@xxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 22 May 2003 11:52:02 -0600



RonKuper@xxxxxxxxxxxx wrote:

I guess my point was like yours - sometimes it is faster and
sometimes it is not. But note that on uninterleaved, panning to surround is definitely faster using SIMD as opposed to not using SIMD. So I think we can't use SIMD-like processing as a reason to support interleaved data formats. It is too case specific.
<<<


Performance is one of the major ways plugin vendors differentiate
themselves.  If we don't allow interleaved processing, then we are designing
out a certain level for performance for some classes of plugins.

This only works if the hosts also differentiate this way. A plugin can always interleave its buffers after receiveing them if the net win is still greater (and obviously deinterleave them at the end). If that net win is not there, then these plugins will actually be slower on hosts that use uninterleaved internally, because the interleaving will be happening in the host.


Accepting interleaved also makes > stereo N times more complicated. Then, not only do we have to worry about speaker postions mapping to buffers, but we start having to worry about the ordering of interleaving. Your 5.1 plugin may use L, R, Ls, Rs, C, LFE, and my host might use L, C, R, Ls, Rs, LFE. If the buffers are uninterleaved, this is not a serious problem (just moving pointers around). If the buffers are interleaved, this is a performance disaster. So that would mean that realistically we would have to consider every surround ordering as a different audio format type. Yuk!

--
Mike Berry
Adobe Systems


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