YouDontHaveEnoughBass
Active Member
- Joined
- Feb 13, 2026
- Messages
- 142
- Likes
- 201
Works brilliantly thanks!
-
Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
GSonic Reference – Free Stereo Room Correction Tool (Measurement + FIR Export)
Hello. I want to use Gsonic filters with Volumio and the FusionDSP (CamillaDSP) plugin. However, this requires filters for every sample rate—44.1, 48, 88, 96, and 192 kHz. So, I have a question: is it better to buy the UMIK-2 (44–192 kHz) right away and create filters in Gsonic for each sample rate by adjusting the device settings in the Windows Control Panel? Or should I use the UMIK-1, import the 48 kHz file into REW, and then export it at 44.1, 88, etc., kHz? Of course, I know I could just resample everything to 48 kHz within Volumio, but I’d rather not... 
- Thread Starter
- #523
Better resample the filters in SoX. The command should be something like:Hello. I want to use Gsonic filters with Volumio and the FusionDSP (CamillaDSP) plugin. However, this requires filters for every sample rate—44.1, 48, 88, 96, and 192 kHz. So, I have a question: is it better to buy the UMIK-2 (44–192 kHz) right away and create filters in Gsonic for each sample rate by adjusting the device settings in the Windows Control Panel? Or should I use the UMIK-1, import the 48 kHz file into REW, and then export it at 44.1, 88, etc., kHz? Of course, I know I could just resample everything to 48 kHz within Volumio, but I’d rather not...
sox -D FL_Filter.wav -b 32 -e floating-point -r 96000 FL_Filter_96k.wav rate -v -s
Explanation:
sox — the converter itself.
-D — global option: no dither. SoX otherwise adds a tiny noise signal when it thinks precision is being reduced. A correction filter should be an exact set of coefficients, not coefficients plus noise.
FL_Filter.wav — the input file. SoX reads its rate, format and channel count from the header, so nothing about the input needs to be stated.
-b 32 — output option: 32 bits per sample. Options placed between the input file and the output file apply to the output.
-e floating-point — output option: encode samples as floating point rather than integer. Together with the previous flag this reproduces the format GSonic writes, 32-bit IEEE float, which CamillaDSP reads and which has no clipping ceiling, so a coefficient slightly above 1.0 survives.
-r 96000 — output option: the target sample rate. On its own it only labels the file; the actual conversion is done by the effect at the end.
FL_Filter_96k.wav — the output file. Naming it explicitly avoids overwriting the original.
rate — the effect that performs the sample-rate conversion, from the input's 48000 to the 96000 declared for the output.
-v — "very high" quality for the rate effect: a long, precise conversion filter. Slower, irrelevant for a file this small.
-s — steep filter: the conversion's transition band starts at 99 percent of the band edge instead of the default 95, so the correction filter's own response is kept intact right up to about 21.8 kHz when going to 44.1 kHz.
Two things the command does not need. There is no -c for channels, because SoX keeps the input's count, so the same command works unchanged on the stereo file. And there is no explicit phase setting, because the rate effect is linear phase by default and compensates its own delay, which leaves the impulse where it was.
For the other rates only two things change: the number after -r and the output name. For 44.1 kHz, -r 44100 and FL_Filter_44k1.wav, and so on for 88200 and 192000.
Last edited:
Noobie question: Does this run the same as Evo 1 Acoustics? Audyssey microphone plugged into AVR, start it and let it do its thing, and results are sent to AVR?
- Thread Starter
- #527
You can use Audyssey mic if your PC has a sound card (a mic calibration file for it is linked under GSonic Immersive video description) but the filters work on PC where you would be playing your music sources from.
Last edited:
- Thread Starter
- #529
A processor will need to convolve 32k FIR taps continuously with the the played content.
Sorry for my ignorance, bad question. Gemini reminded me that GSonic Reference does not include any convolver, just for measuring, filter creation and export.
I plan to use rPi5 as processor, downstream of PC playback (if any). Any disadvantage there wrt GSonic Reference?
How about between HLC vs CamillaDSP as processor
- Thread Starter
- #531
If playback is only coming from a PC, running the convolution directly on the PC (via Equalizer APO, Roon, JRiver, CamillaDSP or HQPlayer) is zero-cost, lower latency, and simpler.
Of course! But as I stated, a PC is only an optional and at most occasional part of my playback chain. And never windoze...
ShadowBoxer
Senior Member
- Joined
- Apr 14, 2024
- Messages
- 468
- Likes
- 332
HLC's convenient ability to A/B filters is like a flashlight in the dark.
RPi will do everything. Make it a playback source. Windows and Mac and iPhone and Android can play to it using AirPlay DLNA whatnot. That is how my set up is. RPi runs the filters and EQ using CamillaDSP. I AirPlay to it. I have mine set to AirPlay 1 so it is always CD quality and never negotiates to lesser streams. CD quality is all you ever need. I would change it to high rez but I don't want to give up the convenience.
Yes I am au fait with rPi capabilities, was just expressing my preferences. Keeping my DSP units independent of playback sources is a design choice.
Anything related to iFruit I hate with the burning passion of a thousand dying suns, been so for over 50 years now, even more so than windoze.
My local networking protocol choice is slimproto from LMS pulling from a large NAS. In my main speaker-based system Wiim Ultra handles render duties just fine, I have a dozen Android control points handy.
Anything related to iFruit I hate with the burning passion of a thousand dying suns, been so for over 50 years now, even more so than windoze.
My local networking protocol choice is slimproto from LMS pulling from a large NAS. In my main speaker-based system Wiim Ultra handles render duties just fine, I have a dozen Android control points handy.
So you have Android control points using LMS to render to WiiM Ultra as an LMS client. Then why don't you use WiiM for EQ?
In an alternate setup, you would use RPi as the LMS client and install CamillaDSP to RPi for EQ. This setup would be without WiiM
In an alternate setup, you would use RPi as the LMS client and install CamillaDSP to RPi for EQ. This setup would be without WiiM
- Thread Starter
- #538
Your AVR is just a power amp in that set up and as such should be kept pure direct/large speakers/volume-distances settings equal for FL and FR which is also what it should be set during the measurement stage.
All my 2ch sources including analog ones, do go through the Wiim besides it acting as streamer source, so who says I don't?
However there is so much signal processing going on downstream - speaker EQ and crossovers with ToF delays and phase tweaking, upmixing to 5.1, subs bass management both stereo and mono, automatic Loudness Contouring tied to the user ad-hoc volume level, plus of course the DRC DSP
While I plan all that out I figure using the Wiim DSP upstream on top of all that likely adds too much more complexity at this point. Maybe once the former stuff is stabilised...
> In an alternate setup, you would use RPi as the LMS client and install CamillaDSP to RPi for EQ. This setup would be without WiiM.
But I have no need for yet another input source, since the Wiim Ultra is in place as a given, acting as my hub - and that includes Squeezelite already - KISS.
Of course distributed RPi & Pico2 units may well play a rôle in the downstream DSP functions listed above,
but as I stated the goal is to keep those separate from the music source components.
Fantastic point in favour that, tx!
Similar threads
- Locked
- Locked