GSonic Reference – Free Stereo Room Correction Tool (Measurement + FIR Export)

[Mattknz]

If I want to use this with camilla dsp do I just load the FL and FR filters into the quick convolution filter section?

 

[OCA]

If I want to use this with camilla dsp do I just load the FL and FR filters into the quick convolution filter section?

Yes you should be able to bypass manual YAML coding and upload them directly.

 

[kifeep]

This little quote by OCA deserves special emphasis. At the moment the only MIMO on the market is Dirac ART. If OCA's MIMO (or whatever he wants to call it) comes to market, there will be no need to pay Dirac's inflated license costs and be locked into their hardware ecosystem. Pay attention here and wait and pray that he gets it working and that it comes to the market soon.

Do I understand correctly that to run a MIMO system like this (or Dirac ART), one needs to be able to apply a different convolution at each point in the signal matrix (e.g. 7x7 matrix or 49 separate convolutions for a 5.2 system)? Is there any hardware that can do this other than a PC (or, again, a Dirac ART enabled AVP/AVR)?

(I suppose CamillaDSP could do it, but that would be a pretty complicated configuration, and I wonder if a raspberry pi could handle it or if you'd need to run CamillaDSP on a full-sized machine).

 

[jeffaegrim]

Alright, so I generally like what the software is doing, but I did run into some issues. Let's look at some measurements.

First off, this is what my L and R look like at the MLP without any EQ at all. The measurement is taken using the moving mic method and it's what I use when I eq the speakers manually. Lately I have only been using biquads, because I kept running into latency issues with other filter types. Due to comments frequently made here by Genelec's Thomas Lund irt auditory envelopment I also stopped using my under powered 10-12" XTZ subwoofers and started running the speakers full range. These are the JBL S3100 mk2 and they make a pretense at having controlled directivity - what with the horn and the 56cm wide baffle - which, I assume, also explains the rather flat in-room response that doesn't sound aggressively bright. Still, I sit relatively close to the horns (2.4m) and usually like to further tilt the HF response by 1.2 db using two wide shelf filters - 6k Q0.3 and 10k Q1.0. It's a multichannel system with a Topping dm7 up front and an Onkyo pa mc5500 driving a couple of speakers, though our interest here is stereo only. Wasapi as the driver, my normal forward-pointing UMIK calibration file and var smoothing all around were used. The speakers have vastly different distances to their respective side walls.

The next two images juxtapose the corrected responses of my speakers taken with a single measurement - once with GSonic (labeled "OCA") and once with my own manual correction (labeled "old"), left and right speaker respectively. The mic has not been moved between measurements but I could only approximate the SPL. I decided to present the traces in this manner, comparing my correction with GSonic's, but you are of course also welcome to look at the measurements (attached below) any way you want yourself.

Even though the SPL is a bit messed up (the GSonic corrected sweeps were WAY quieter and I had to reduce the volume during the "old" sweep for them to be approximately equally loud), we can still see that the correction made by GSonic produced a "prettier" curve overall. I chose the Harman target for the GSonic filters that were used here; for my manual correction, the atmos music target curve was used, which can be downloaded from Archimago's blog. Noteworthy: in my manual correction, I apply a 8db Q1.0 boost at 40hz - the speakers don't care about that one bit and with their 95db sensitivity, neither does my amplifier. It's a rare case of being able to apply pretty much any amount of EQ without consequence (I tried up to 12db), which it is also necessary, as you can see from the unequalized response. Other than that, I only cut peaks and end correction at 300hz. I am not quite sure why my manual correction produces somewhat better looking results in the VLF range than GSonic. Let's look at the right speaker though.

So, this is a bit weird - the GSonic correction completely missed this 270hz peak! Other than that, I'd say this looks pretty good - it also sounded pretty good, though I didn't listen for long, as I had to take more measurements. I figured that the peak could have been missed by the software due to me using an unusually large spacing between measurements, which I did assuming that it would compensate for the fact that GSonic takes only three of them. This meant I had to take the measurements again, paying attention that the three mic positions are closer to each other this time - covering a smaller area akin to the one in which I usually take MMM measurements. This is what I ended up with:

During these sweeps the mic hasn't been moved. While we (once again) have a pretty measurement, this time GSonic decided not to boost the low bass at all. Taking new measurements for GSonic did, however, solve the issue that the right speaker had:

For good measure, here's the L speaker phase response with my manual correction compared to the L speaker response with correction done by GSonic:

Summa summarum, I think there is a ton of potential here, but I think I might be missing some functionality - like maybe being able to select the number of measurement points or the amount of boost applied. Perhaps some more detailed guidelines to the end user regarding the fine points of the measurement procedure - e.g. spacing - could be included in order to further streamline the software and ensure repeatability. Human error on my part is possible of course, too, even though I tried to follow instructions closely, for which I apologize in advance. I am also not sure whether correction in the high frequencies is taking place - it does look like it, which is confusing to me, since your usual stance seemed to indicate that you're against correction in that range. My main issue right now would be the low bass though, which I am now missing. Bigger boosts were applied by GSonic to my first suit of measurements, but not the second. I would be satisfied with this first set of filters, if only not for that visually jarring right speaker 270hz peak! As you can see, my further attempts fixed one issue and raised another. Any ideas what a solution could be?

I further also invite you to take a look at the spectrogram, as I seem to see some irregularities in the high frequencies.

Lastly, one of my compression drivers is a little bit busted - it has higher harmonic distortion at XO and plays slightly quieter, which is why I have to reduce the volume of the right speaker by 0.7db. Is there any way for GSonic to be able to consider that fact during measurement or filter creation? Due to WASAPI/ASIO routing it ignores EQapo settings, I assume.

Hope this has been somewhat helpful, anyhow.

 

[OCA]

Congrats on being the first brave soul to use the app - 200+ downloads so far but not a single sound feedback other than yours

I will try to explain every single one of your questions.

GSonic corrected sweeps were WAY quieter

They are -12dBFS (REW default) at origin and the final sweep volume should be adjusted with your amp to your regular listening levels.

GSonic correction completely missed this 270hz peak

You didn’t provide the GSonic measurements (which should have been saved in a folder) or the generated filters, so I can’t review the specifics. However, it appears that the peak is localized and wasn’t present at the far microphone positions you measured—you seem to have already noticed this in your second attempt.

The app assumes microphone placements are within the “true” stereo listening area, which is typically not very large. It’s not designed to deliver uniform bass across multiple seats; instead, its purpose is to preserve the best possible sound quality at the main listening position (MLP).

Additionally, because it relies on differences between mic positions (spatial distillation) to switch filter types, spreading the measurements too far apart will cause minimum-phase correction to stop earlier. This happens because shared characteristics across positions decrease, whereas tighter mic groupings naturally allow correction to extend to higher frequencies.

the atmos music target curve was used

This must be the reason for the lack of bass in your second attempt. This curve embeds a bass roll off, it's not flat (unless you fixed it first). There is a warning in the app for avoiding to use target curves with embedded bass roll-offs. GSonic calculates the natural roll off point of the measured speakers very precisely and boosts or cuts LF response accordingly.

It's a rare case of being able to apply pretty much any amount of EQ without consequence (I tried up to 12db)

It's possible the dip in that region is minimum phase but maybe you just can't hear the distortion since very few music tracks have any real content in that region. GSonic will only boost what can be boosted with a very special algorithm.

your usual stance seemed to indicate that you're against correction in that range

That's because with the Audyssey interface, we were strictly limited to min phase only filters. GSonic uses a hybrid filtering approach with symmetrical excess phase transient gating.

Due to WASAPI/ASIO routing it ignores EQapo settings

ASIO will bypass Equalizer APO but I doubt that Wasapi would. If I remember correctly, APO installs itself deep into Windows audio kernel. I see some time delay differences between your left and right speaker tweeters which could be some filter engaged during measurements. GSonic will volume align left and right speakers to each other.

Lastly, those phase graphs include "time of flight" which should be removed (i.e. REW's "Remove IR delay"), then you will not see these phase rotations. If you are not seeing a flat phase response in your results and there are major differences between your left and right speakers, that usually points to some set up problem during measurements.

 

[OCA]

Do I understand correctly that to run a MIMO system like this (or Dirac ART), one needs to be able to apply a different convolution at each point in the signal matrix (e.g. 7x7 matrix or 49 separate convolutions for a 5.2 system)? Is there any hardware that can do this other than a PC (or, again, a Dirac ART enabled AVP/AVR)?

(I suppose CamillaDSP could do it, but that would be a pretty complicated configuration, and I wonder if a raspberry pi could handle it or if you'd need to run CamillaDSP on a full-sized machine).

I am not very familiar with CamillaDSP internals but I can confirm none of the Roon, JRiver, Equaliser APO convolution engines can do cross mimo filtering and CamillaDSP was the only one which had potential from what I read about it.

The convolution process itself doesn't require that much speed for stereo which can be a 2x8 matrix max so could be handled with a RPI I guess but 16 channel Atmos is tough even for PCs unless you use heavy filter downsampling and multirate algorithms like ART does (uses 1024 tap filters of varying sample rates per speaker/sub)

 

[ImageMaximum]

Is anyone else having trouble getting the Mac intel version working? Since version 1.0 I always get Bad CPU type in executable, no matter what I do.

 

[OCA]

Is anyone else having trouble getting the Mac intel version working? Since version 1.0 I always get Bad CPU type in executable, no matter what I do.

I am looking into this. Thanks for reporting.

 

[OCA]

Interesting, github seems to have retired Intel macOS runners and now defaults to apple silicon only! I tried a workaround with v1.0.7 uploaded just now. Please let me know.

 

[ImageMaximum]

Interesting, github seems to have retired Intel macOS runners and now defaults to apple silicon only! I tried a workaround with v1.0.7 uploaded just now. Please let me know.

Yes it is finally working now, thank you

 

[OCA]

I added a startup debug log to clearly see issues if a premature exit event happens with v1.0.8 (no other change from v1.0.7 and you don't need it if your app loads fine)
gsonic_debug.log is a text file and will be saved in the app folder during start up. If you are having problems, you can share that file and it will be much quicker to resolve any issues.
I will remove it later in future versions once all existing/potential problems are ironed out.

 

[ImageMaximum]

Did a quick test run and everything seems to be working. The only problem seems to be that I can't load the mic cal file. Both "Browse" and "Load Cal" Buttons don't seem to do anything in the Measurement Setup section (output path can be selected manually though). On the Generate tab the browse button works as expected.

 

[OCA]

Both "Browse" and "Load Cal" Buttons don't seem to do anything in the Measurement Setup section

This and a problem with older outdated Windows VC++ runtime have been fixed now with v1.0.11
Switched to static CRT linking and the entire C++ runtime is now embedded in GSonic.exe. Zero external DLL dependencies. Works on any Windows 10/11 machine regardless of installed runtimes. Special thanks to @thewas for patiently helping out to resolve that issue.

 

[jeffaegrim]

Did a quick test run and everything seems to be working. The only problem seems to be that I can't load the mic cal file. Both "Browse" and "Load Cal" Buttons don't seem to do anything in the Measurement Setup section (output path can be selected manually though). On the Generate tab the browse button works as expected.

Had a similar issue with being unable to select the input device with an ASIO driver - switching to WASAPI alleviated the problem.

The app assumes microphone placements are within the “true” stereo listening area, which is typically not very large. It’s not designed to deliver uniform bass across multiple seats; instead, its purpose is to preserve the best possible sound quality at the main listening position (MLP).

Thank you for the detailed response - that certainly makes sense.

This must be the reason for the lack of bass in your second attempt. This curve embeds a bass roll off, it's not flat (unless you fixed it first). There is a warning in the app for avoiding to use target curves with embedded bass roll-offs. GSonic calculates the natural roll off point of the measured speakers very precisely and boosts or cuts LF response accordingly.

I think we misunderstood each other here a little bit - I used the atmos music curve previously, for my manual corrections only. In GSonic, I only used the targets provided by you - switching the target curves also didn't change much in the VLF range. I'll attach the latest measurements done in the GSonic software with this post. It's a pity, but I only have the newer measurements ("revised" measured response in previous post), as GSonic saved over my first suit of measurements. Perhaps an option to rename the measurements GSonic makes in case they are being saved in the same folder?

It's possible the dip in that region is minimum phase but maybe you just can't hear the distortion since very few music tracks have any real content in that region. GSonic will only boost what can be boosted with a very special algorithm.

The speakers just have a very early roll off, I believe. They have been produced for the japanese market and the designer himself, Greg Timbers, opines that a ~6db boost at around 40hz is necessary for most of these JBL models. Distortion in the VLF range is completely room dependent I think, which is why it's e.g. higher at 60hz than at 30hz for the left speaker.

That's because with the Audyssey interface, we were strictly limited to min phase only filters. GSonic uses a hybrid filtering approach with symmetrical excess phase transient gating.

I understand the gating part of your response - but, given some free time, could you perhaps elucidate the process here a little bit? I am now conditioned - by you, among others - to be very skeptical of any HF correction. Perhaps a related question: does one need to use the minimum phase version of the mic calibration file for GSonic?

ASIO will bypass Equalizer APO but I doubt that Wasapi would. If I remember correctly, APO installs itself deep into Windows audio kernel. I see some time delay differences between your left and right speaker tweeters which could be some filter engaged during measurements. GSonic will volume align left and right speakers to each other.

Very interesting, thanks for the explanation, this is invaluable in my further testing. Indeed, in EQAPO, two HF filters were engaged; additionally, both speakers had a 20ms delay dialed in to align them with the rest of the system and the 0.7db was dialed in before taking GSonic measurements. I will try the procedure again with all filters in EQAPO disengaged. I remain however somewhat uncertain on the low bass issue - here, the correction worked clearly better the first time around (with wider mic spacings) and from my understanding, the issue shouldn't have been caused by me using a wrong target.

Lastly, those phase graphs include "time of flight" which should be removed (i.e. REW's "Remove IR delay"), then you will not see these phase rotations. If you are not seeing a flat phase response in your results and there are major differences between your left and right speakers, that usually points to some set up problem during measurements.

Re: phase - removing IR delays helped - both GSonic corrected and "manually" corrected phase responses can be seen below (same as above but with IR delays removed). Here, I am not quite sure what level of flatness we are aiming for.

GSonic corrected phase response for L/R:

Phase response with my manual filters, L/R (that phase rotation at crossover is gone in the GSonic produced plots):

 

[OCA]

Perhaps an option to rename the measurements GSonic makes in case they are being saved in the same folder?

Good idea, noted thanks. For the time being, you can save them in a different folder each time.

does one need to use the minimum phase version of the mic calibration file for GSonic?

No, GSonic already does that internally.

the issue shouldn't have been caused by me using a wrong target.

Your MLP might be right by a room mode null and only wider mic positions captured it perhaps. I am sure you will find the optimal mic spacing/pattern required for your set up. But your results (vector average of left + right before and after using the filters shown) seem inline with what the speakers are capable of:

You may try adding peaking filters around 40Hz in addition to the convolution filters in Equalizer APO.

There seems to be a problem with left speaker's driver at around 7kHz causing a sharp phase rotation in the measured response (unless there's a filter engaged during measurement). Even 1/1 octave band smoothed excess phase inversion couldn't smooth it out and the drop in SPL at around 7kHz in the summation of left and right speakers is also showing the phase mismatch.

The slight tilt in the general phase response is normal. Both of the speaker impulse responses have twin peaks (I guess specific to the HF drivers in your speakers) and don't align to t=0 perfectly.

 

[OCA]

GSonic Reference v1.0.12 released. All known/reported issues and suggestions resolved.
Details in change log in Github.

 

[jeffaegrim]

No, GSonic already does that internally.

Very good to know.

Your MLP might be right by a room mode null and only wider mic positions captured it perhaps. I am sure you will find the optimal mic spacing/pattern required for your set up.

That's what I will be trying to achieve in the coming days. In the meantime, I have listened to the first set of filters I generated for a few hours and want to provisionally declare GSonic a success - while it's difficult to make AB comparisons due to difference in level, the correction produced by GSonic in mere minutes sounds very good and coherent. I am carefully optimistic in regards to the slight changes in the high frequencies produced by GSonic - the overall balance seems to be improved somewhat.

You may try adding peaking filters around 40Hz in addition to the convolution filters in Equalizer APO.

Awesome - I was wondering about that.

There seems to be a problem with left speaker's driver at around 7kHz causing a sharp phase rotation in the measured response (unless there's a filter engaged during measurement). Even 1/1 octave band smoothed excess phase inversion couldn't smooth it out and the drop in SPL at around 7kHz in the summation of left and right speakers is also showing the phase mismatch.

Very interesting - that would be the problematic driver, yes - though I wonder how audible this is, considering there is little impact on the FR. Kicking myself for months for not buying a spare pair available in Japan last year. These compression drivers are absolute and utter unobtainium. There is a guy on the Lansing Heritage forum that spent 15 years looking for one, having to give up in the end.

This was not correct, sorry. I saw a similar issue in another filter and it's a minor bug in the algo causing this. Working on a fix...

Ah, this explains that then. There is a corresponding "splash" visible in the spectrogram...

The slight tilt in the general phase response is normal. Both of the speaker impulse responses have twin peaks (I guess specific to the HF drivers in your speakers) and don't align to t=0 perfectly.

The JBL S3100 have variable directivity depending on angle - I always assumed some measurement irregularities are a given. Very unconventional design.

In any case, I am excited about the possibilities of GSonic and am eagerly awaiting the next iteration of the software. I've been doing this for a while in this terrible room of mine and it is very difficult to get results as good as these - especially from what is essentially 100% freeware. If I can be of any further assistance in any form of testing, please let me know.

(Admittedly, my speakers are far from being the "default" case in home stereo...)

 

[OCA]

Very unconventional design.

True, gave GSonic an early battle test but they measure very very good otherwise. I have fixed that minor bug causing 7kHz phase jump with some measurements and version is still v1.0.12. Any more phase anomalies, it's your driver

 

[jeffaegrim]

True, gave GSonic an early battle test but they measure very very good otherwise. I have fixed that minor bug causing 7kHz phase jump with some measurements and version is still v1.0.12. Any more phase anomalies, it's your driver

Trial by fire, so to speak Thank you for your efforts! Can't wait to generate a new set of filters.

To anyone reading - my enthusiasm in the post before this one was downplayed; GSonic really does an amazing job. I used the word "coherence" once and after some more listening that's what I'd like to reiterate - the system measures better and sounds more coherent with the GSonic filters in place. So much that it's almost a case of "I don't want to go back to using my old EQ presets anymore" - even though I had little complaints about my previous setup. There were no setup issues and no issues loading the filters into the convolution engine, the procedure is easy and painless. Very good stuff.

 

[3ll3d00d]

I am not very familiar with CamillaDSP internals but I can confirm none of the Roon, JRiver, Equaliser APO convolution engines can do cross mimo filtering and CamillaDSP was the only one which had potential from what I read about it.

would you really need a complete matrix? intuitively that would seem quite unusual (aka not all speakers in a typical multichannel setup are similarly capable)

on 1st impression, I'm not sure why it wouldn't work in jriver, you certainly can't do multipass convolution (whereas cdsp, afaik, can) but you can do multipath for any channel which is all you need in this case isn't it?