Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Paul W]

Similar to the recommended sequencing in the overall DSP studio, what is the optimal sequencing of tasks within the PEQ function?  Group by task type for all channels (mix, delay, PEQ, etc), do everything to one channel before moving on to the next, etc.  What is the most bullet-proof approach?

This is for an 11.1 system with bi-amped LCRs so I have a lot going on in DSP studio.  No audio problems at this point, but figure an ounce of prevention...

[mwillems]

Similar to the recommended sequencing in the overall DSP studio, what is the optimal sequencing of tasks within the PEQ function?  Group by task type for all channels (mix, delay, PEQ, etc), do everything to one channel before moving on to the next, etc.  What is the most bullet-proof approach?

This is for an 11.1 system with bi-amped LCRs so I have a lot going on in DSP studio.  No audio problems at this point, but figure an ounce of prevention...

I've been using JRiver for my bi-amped setup and have been doing a lot of DSP manipulation, and with a few obvious exceptions it seems to be pretty insensitive to the order of operations.  Obviously you want to copy channels early before you start doing the crossovers, etc, but that's pretty straightforward.  I've done a lot of measurements, and I've rarely noticed that the order of operations has much effect (again, except in really obvious cases like applying EQ before splitting the low from the high). 

The main "effect" of order of operations for me is convenience when manipulating the settings later.  For example, I like to tinker with convolution and linear phase crossovers, but I like to be able to switch back and forth from my FIR crossovers to JRiver's IIR crossovers (for A/Bing, or when latency is an issue).  In order to facilitate that EQ I keep my bi-amp settings split up across the two PEQs:

1) PEQ module #1 copies and routes the channels, applies delay, and adjusts the total volume of the channels, but does no EQ or crossover filtering.
2) PEQ module #2 does all the crossovers, EQing, and shelving, etc.

I order PEQ1 before convolution and set PEQ2 after convolution so I can A/B with two clicks (turn on convolution, turn off PEQ2, etc.). 

But I'm interested to see others experiences as well. If anybody has measured a significant difference in the order of operations, I'd be very interested to hear it myself!

[natehansen66]

I use the PEQ for a 3-way xo and eq, with the channel mixing/routing at the top. I do all eq and xo filters in the same PEQ block for all drivers. I haven't see any measureable difference in filter placement below the channel routing. In my setup, I run convolution before the PEQ for phase linearization (is that a word?) and drc so the effect is global. Seems to work quite well. I've been running this way for a little over a year now.

[Matt]

Obviously the effects go in order from top to bottom (drag to reorder), so sometimes the order is important for getting the sound right.

There's no sound quality difference with regards to order -- at 64-bit, you have billions of times more precision than the output so you can ignore any ideas of rounding errors, etc.  This sometimes surprises people, but doing 100 million volume changes provides bit-identical output to one combined volume change at 32-bit output (the highest known hardware output bitdepth).  Proof here: http://wiki.jriver.com/index.php/Audio_Bitdepth#Bit-Perfect

There could be minor CPU usage differences depending on ordering (due to cache hits, misses, etc.) but it's going to be minor.  I don't think it's even worth thinking about this.

I've considered trying to get clever here and combine effects in certain cases, or process different channels on different threads, but the complexity isn't a clear win.  A modern computer is so ridiculously fast at this type of floating point math that it's unlikely to make much difference.  Especially in the case of threading, the overhead of the threads sometimes costs more than the parallelism gains when doing small chunks of processing.

Hopefully some of the above helps with the original question.