MSO- Multi Sub Optimizer Beginners Thread

  • Thread starter Thread starter NorCalRP
  • Start date Start date
I'm going to just run it again. Last night I moved my MLP forward about a foot to get it a 1/4 length off the wall- my HSU was also directly behind it, so it was localizing. I moved my SVS out of the corner as well.

I downloaded Jerry's guide and should get a chance to take a pretty good look at it today.

If my thinking is correct, the real benefit if Audyssey in this scenario is to set the distances on my speakers, right? Using just sub-out 1 for all three subs seems like the distance measurement would be meaningful. Plus, REW/MSO does this for me, yes?
 
Changed the name. Optimizing these three is going to be good practice... I just ordered another PC-2000, so when #4 comes into the mix I'll be doing everything over.
 
  • Like
Reactions: andy_c
If my thinking is correct, the real benefit if Audyssey in this scenario is to set the distances on my speakers, right?

I think that's a fair statement, yes.

Using just sub-out 1 for all three subs seems like the distance measurement would be meaningful. Plus, REW/MSO does this for me, yes?

MSO can determine the sub distance in your AVR (or rather the amount you need to increase or decrease the sub distance from the value that was used in the measurement). This only works with MSO "subs + mains" configurations, though, not "sub only" configurations.

This brings to mind a kind of paradox that leads to the reason why the "sub only" configurations were added. Originally, only "subs + mains" configurations were available, which do optimum integration of mains and subs. For optimum integration of mains and subs, you need to run MSO after Audyssey, because you need to have all the distance settings and EQ of the mains in place in order to get the sub distance and sub EQ in the crossover region correct. So you need to run Audyssey first. But, with multiple subs, the initial settings for individual sub delays and such may be way off, causing a large frequency response variation in the combined sub responses. Running Audyssey in this condition would cause Audyssey to make large response corrections using EQ that's common to all the subs. However, these problems are due to the subs not combining nicely, not necessarily due to some problem that should be fixed by applying aggressive common EQ. To get them to combine nicely, you want to run MSO first and Audyssey last. :) So the "sub only" configuration type was created. The idea is to get the subs playing together nicely before running Audyssey, so Audyssey doesn't need to EQ the combined sub responses very much at all.

However, Audyssey tends to do a poor job determining the sub distance, so this now leaves the issue of optimizing the sub distance unaddressed. Some people have run MSO a second time with a "mains + subs" configuration after running Audyssey, but this is somewhat overkill for just a distance adjustment. Dirac users have found that Dirac does a very good job determining the sub distance, so they don't have to mess with it any further. Another option is to do a variant of the manual "sub distance tweak", using the REW RTA with a periodic pink noise source ("pink PN") to measure and observe changes in the combined mains and subs' response in real time. One can adjust the sub distance and observe the response changes in real time due to these changes. REW author John Mulcahy has posted the REW RTA settings for this scenario. This is one we may have to play by ear. I haven't had to deal with this myself, as I'm a two-channel guy and I only do EQ below 200 Hz - no room correction.
 
Found out about this reading a nap note on the mini DSP website. I searched here to see if there were any dedicated threads, to no avail. It looks really promising- and might make my purchase of Dirac Live a waste of money (I wonder if I could transfer the user license to someone else if I don't download it on my PC).
Thanks for posting!
I had not heard of MSO (aside from the Milwaukee Symphony Orchestra!)!
 
Finally has a reasonably short day at work. was able to come home with time to actually get started on measuring everything. I moved my couch forward so my MLP is a quarter length off the back wall. Also positioned my 3 subs in accordance with how a 4 sub setup might be positioned- my SVS PC-2000 front right at 3/4 length, the Ultimax 18" back length at 1/4 length and the HSU VTF-3 MK4 back right at 3/4 length. I have another PC-2000 ordered, and will run measurements on it and incorporate them once it's placed front left at 1/4 length. All the subs are about a foot off the wall, btw.

Before taking the first measurement I can say that there are definitely some mode issues, and I feel like I have a pretty significant spike in the 100Hz region. We're about to find out though!
 
  • Like
Reactions: andy_c
Uh oh... I just looked up what MSO is and I've been tweaking stuff with REW/MiniDSP the last couple of days ...
 
  • Funny
Reactions: KEW
IMG_20190922_180106.jpg


These are the initial measurements of each sub, all three positions averaged.

IMG_20190922_180403.jpg


This is all subs averaged (the average of the three above averages)

IMG_20190922_180816.jpg


The red line is the average of all 9 individual measurements.
 
@andy_c
IMG_20190922_181931.jpg


I'm unable to see the cursor data. I can't figure out how to get the output readings in view
 
Hi @andy_c

I'm kind of cheating on the tutorial, and using my own measurements to try and get my personal optimization performed, as I'm excited to compare my original measurements in REW with my post-optimization measurements. It's saying I must have a mains measurement to go along with the sub measurements. I didn't take those measurements. Any tricks on how to get around that?
 
I'm trying to do a sub only optimization, but it's not allowing me to add a delay block filter on my 3rd sub
 
Hi @andy_c

I'm kind of cheating on the tutorial, and using my own measurements to try and get my personal optimization performed, as I'm excited to compare my original measurements in REW with my post-optimization measurements. It's saying I must have a mains measurement to go along with the sub measurements. I didn't take those measurements. Any tricks on how to get around that?

You created a "subs+mains" configuration, which requires mains measurements to run the optimization. You'll need to create a "sub only" configuration.

I see you just posted about not being able to add a delay block to the 3rd sub, so I assume you've got "subs only" vs. "subs + mains" figured out? I'll answer that separately.
 
I'm trying to do a sub only optimization, but it's not allowing me to add a delay block filter on my 3rd sub

There's a section in the documentation that talks about restrictions on delays for sub-only configurations. For sub-only configurations with N subs, there can be only N-1 delays. One channel gets no delay, while the others get positive delays. If you have one sub that's more distant from the main listening position (MLP) than others, that's the one that gets no delay. Otherwise, you have to use a trick. For three subs, arbitrarily pick two channels to assign a delay, but... get this... allow the delays to be negative (e.g. allow the delays to go from, say -15 msec to +15 msec). After running the optimization, do a "normalize delays" command. This will figure out which sub channel gets zero delay, rearrange the delay blocks as necessary, and make the delay values all positive. It's discussed in the "tips and tricks" section called "Rearranging and Normalizing Gains and Delays".
 
There's a section in the documentation that talks about restrictions on delays for sub-only configurations. For sub-only configurations with N subs, there can be only N-1 delays. One channel gets no delay, while the others get positive delays. If you have one sub that's more distant from the main listening position (MLP) than others, that's the one that gets no delay. Otherwise, you have to use a trick. For three subs, arbitrarily pick two channels to assign a delay, but... get this... allow the delays to be negative (e.g. allow the delays to go from, say -15 msec to +15 msec). After running the optimization, do a "normalize delays" command. This will figure out which sub channel gets zero delay, rearrange the delay blocks as necessary, and make the delay values all positive. It's discussed in the "tips and tricks" section called "Rearranging and Normalizing Gains and Delays".

The reasons for this craziness have to do with optimizer convergence. For sub-only configurations, the only aspect of sub delays that matters is the relative delay between subs. So if you had an optimum configuration and added 1 msec delay to all subs, it would still be optimum. If you add the same delay to all subs in fact, no matter what the value of that delay is, the solution would still be optimum. This means there's an infinite number of such equal delays you could add to all the subs for an equivalent result. This kind of situation causes optimization algorithms to spin their wheels forever, so I have to enforce these restrictions.
 
I'm trying to do a sub only optimization, but it's not allowing me to add a delay block filter on my 3rd sub
I just ran it without the delay block on the sub it wouldn't allow me to put it on
 
About 4 minutes in and it's already looking WAY BETTER!!!:D:cool:
 
I just ran it without the delay block on the sub it wouldn't allow me to put it on

If any of these delays come up zero, it's means the optimizer has "hit the stops" and is a sign that allowing negative delays is likely to improve things.

The long optimization times suggested in the documentation can be relaxed a bit, because I modified the code to use multi-threading in the optimization. So if you have a multi-core processor, that will help a lot. When I changed to multi-threading, the optimization ran about 3.5x faster on my quad-core processor than it did before.
 
If any of these delays come up zero, it's means the optimizer has "hit the stops" and is a sign that allowing negative delays is likely to improve things.

The long optimization times suggested in the documentation can be relaxed a bit, because I modified the code to use multi-threading in the optimization. So if you have a multi-core processor, that will help a lot. When I changed to multi-threading, the optimization ran about 3.5x faster on my quad-core processor than it did before.
I have a Dell XPS 15 with an 8th Gen Core I7, so 6 cores. The graph changed only slightly past about 2 minutes.
 

Latest posts

newsletter

  • RBHsound.com
  • BlueJeansCable.com
  • SVS Sound Subwoofers
  • Experience the Martin Logan Montis