[gmpi] Re: Decision Time: 7.1.1
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 10 Jun 2003 09:04:51 -0400
>One final point. Our mix engine is able to render fades one sample at a
>time. We can't take away this feature; it's been in our product for years.
>It gives us a competitve edge. If we go to uninterleaved, and want to
>leverage SIMD in our mix engine, we can no longer render sample by sample
>(we need to go to a 4-sample control rate). Can't do that.
ron - i still don't understand why you believe that SIMD requires
interleaving in the general case. ardour always renders per-sample
fades, could use SIMD instructions, but doesn't because at this point
in time, i have more important things to focus on (plus my main
development system is still a PII).
can you try to clarify why you think interleaving and SIMD go
together? i maybe missing something blindingly obvious ...
i am also a little suprised at you quoting 4 examples of microsoft's
allegiance to interleaved format. in the preamble to the gmpi effort,
one of the points i think you made was that we (the audio software
industry) need to be free of the control and dictates of operating
system vendors. if this forum were to decide that non-interleaved is a
better solution when viewed all around, isn't the whole point to be
able to follow that decision rather than what MS decides? and just
look at what has happened with AU where as i understand it, apple
started out interleaved and then following "developer pressure"
switched? i hope this is not going to devolve into another "2 worlds"
kind of thing ...
finally, to reiterate one last point about CPU usage. i am very
puzzled that your silence optimizations don't upset your customers
more than they apparently do. as steve and others pointed out, one of
the major differences between DSP-chip based solutions and those using
generic CPUs is the total predictability of the load for the
former. optimizing silence in tracks means that the load varies
(perhaps dramatically), and in ways that may be "obvious" to the user,
but are still not theirs to control. i would be less disturbed by
SONAR/GMPI having slightly higher CPU usage (which, after all, will be
compensated for by the next release the CPU) than i would be by
finding that my system flakes out when all 36 tracks (or whatever)
have audio data in them, but works ok in sections where 5 of them are
"empty".
--p
----------------------------------------------------------------------
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:
