Russell Ryan wrote: > > Could you explain what you mean by inefficient? Each EngineObject is > only dealing with pointers to the audio data that it modifies, so each > channel only works on one buffer of data. If you mean that each > EngineObject that runs will potentially loop over bufferSize samples, > then I agree, this is inefficient, but I'm not sure it's significantly > inefficient. EngineChannel runs 3 sub-processes : pregain, filtering, > and clipping. Assuming each EngineObject can be written to take 1 pass > over the data, this is not terrible -- 3 total iterations over the > buffer. Is it desirable to sacrifice code organization and modularity > in order to fold 3 separate loops into 1? If a subroutine does as ridiculously little just as enginevolume or so, yes. Making a on-liner a complete engine is a big waste, and it doesn't improve legibility of code at all. In addition, note that these micro-effect-engines do much more address calculation and data movement then effective work. Just look at the assembler code each process produces, and compare it to a "mulss xmm1, xmm2" that does the work.I guess you wouldn't even notic a speed difference if it wasn't a single buffer but a chain of buffers. > > I notice that EngineFilterBlock does 4 separate passes over the data > (since it runs the low, mid, high eqs and then merges them) -- I'm > assuming this can be improved, which I would definitely welcome. > > SIMD-izing our code is a major improvement that we should take > advantage of. Easy to calculate LP/BP and BP/HP concurrently, if desired (totally undesirable for me). > I like how you've re-written the mixing so that we support an > arbitrary number of channels. More than 2 channels in Mixxx is way > down the line from here, Unfortunately. I'd like it ASAP. > but that doesn't mean we can't plan for it.
> >> EngineVUmeter got an additional method that takes the precalculated >> peak and rms (and dumps the peak value, because the wvumeter can't >> cope with two values). >> >> Both engines use functions that are designed for SIMD calculation, >> i.e. applying the same operation on multiple data concurrently. The >> current SSE implementation is written AT&T style for gcc (I don't >> know if MSVC will accept that), and uses 64bit opcodes. Porting to >> 32bit should be easy, just replacing rXX register names by eXX names. >> There's also an alternate pure C++ version included (function names >> without Asm), emulating the SSE SIMD instructions which should be >> runnable on any platform. > We'll need to give some thought to splitting the SSE from the pure > implementations and making the SSE code portable. All asm lines could be calls to macros, so there are 4 sets of asm macros (AT&T and Intel syntax, 32 and 64 bit each). Regards, Andreas ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
