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