LinFIR – DSP Software for FIR/IIR Filter Design and Speaker Correction

[Waveform Fidelity]

Hi Arnaud,

I spent the afternoon playing with the software and know how hard it is to develop these products that will satisfy many and how beta reviews can be harsh. My intention is to be helpful and hopefully my comments come out that way

I have some feedback.

1. Generally the UI display, quality of the graphs etc is really very nice and got nice look and feel. I like how the imported FR is immediately converted to an impulse response - that's a nice feature.

2. However, from a user standpoint, I found the UI layout confusing and not easy to follow. Just one example - names such as "FIR filter" located under the driver tab seems wrong to me.

3. In my opinion, the workflow of the tool could follow more logical steps and order for loudspeaker design. For example:

Step 1. User is guided to import (or measure) driver response (tool is good, but the step out of order of workflow) -->

Step 2. User selects desired acoustic targets (e.g LR8 bandpass fc = 400Hz, 3000Hz) - this step could be improved a lot-->

Step 3. Tool shows the correcting filter design (shows the target, driver and equalizing filter response, and allows the user tools, taps, window, Fs, etc to be adjusted so that user can interact with the tool to see real time effects of increasing tap, changing windows, add IIR etc - this is the major step of the workflow, it would also have auto EQ and manual tweaking and the end result is the "correcting filter" mag/phase which should clearly display; a. Driver response b. correcting filter and c. acoustic target

Step 4. Export the FIR/IIR correcting filter to target hardware.

In my opinion, in the current UI design, these steps are not obvious. The targets are hidden away and the user is asked to add "points" to define the desired response, or create and import customer target data from excel. Why not have LR and other shapes pre-made as targets? its very valuable and avoids the user having to go outside the tool. In the current UI it's very easy to mistake the FIR configure button located under "driver" as the target - because one is desperately hunting to find where to set the target acoustic response. Also, the filter is not part of the driver - the two are different and separate things -the FIR filter (configure) button is in the wrong place.

If the goal is to commercially sell this as a successful product, it's the user interface that should be great (good enough is, well, not good enough). Also, the UI design cannot be left up to the developer (1st major mistake in any UI design). Why? because the developer is influenced by his/her software design, and the UI design is influenced by that (a professional UI developer may be able to expand on that industry wide observation). Instead, my suggestion is enlist the help of a pro-audio engineer, that is faced every day with creating EQ filters and crossovers in practical situations to help you with UI prototyping.

Hope this feedback is of some help.

With the UI changed to make it easier to use (not necessarily my steps), I would consider purchasing a license.

Best regards

 

[Arnwald]

Hi, thanks for taking the time to provide such detailed feedback.

Regarding the workflow, LinFIR’s core philosophy is explained at the beginning of the documentation (https://demaudio.com/doc/linfir/overview.html#design-philosophy). The app is designed to mirror a real-world DSP signal chain, where a Driver tab represents a physical output channel. This is a deliberate engineering choice to ensure the software remains aligned with the hardware's behavior.

On the Target Curves vs Crossovers: I purposefully decoupled them. In loudspeaker design, attempting to hit a complex acoustic target (linearization + crossover slope) in one go often leads to phase errors or double-filtering. My approach is to first flatten the driver response via the Target, then apply the Crossover. This ensures the acoustic slope is mathematically accurate. While I agree the UI for creating target curves can be more intuitive and I am looking into it, keeping these steps separate avoids a layer of abstraction that can lead to errors for both novice and advanced users.

Regarding Taps and Sample Rate: This is where I have a fundamentally different view. A FIR filter’s actual response is strictly dictated by Fs and Tap count. Showing a perfect theoretical curve and letting the user discover later that the low-frequency resolution is poor or that the filter rings is exactly what I want to avoid. LinFIR is built on a WYSIWYG principle: you set your hardware constraints first so that every adjustment on screen is physically achievable by your DSP. This prevents misleading idealized simulations and saves the user from constant back-and-forth between settings and export.

I appreciate the perspective and will take these points into account as I continue to refine the interface.

Best regards,

Arnaud

 

[Waveform Fidelity]

Hi Arnaud,

Thanks for the reply which help me put the current design approach in perspective.

Is it possible to add the means to import tabular values representing a target curve? At the moment the user has to define each point, so that a lot of points if the target has a “shape”

Best regards

 

[Arnwald]

Hi Arnaud,

Thanks for the reply which help me put the current design approach in perspective.

Is it possible to add the means to import tabular values representing a target curve? At the moment the user has to define each point, so that a lot of points if the target has a “shape”

Best regards

That is a good idea! I'll add an import and export button to save and import complex curves.

 

[Arnwald]

LinFIR 1.2.17 is now available.

This release introduces dedicated project modes for Hypex FusionAmp platforms. These modes reflect the actual hardware constraints of the amplifiers: the DSP runs at 93.75 kHz, the driver count matches the amplifier configuration, and the available DSP resources are enforced automatically. Two FIR processing layouts are supported: a global input FIR with up to 4500 taps, or per-driver/output FIR filters limited to 1500 taps each. The IIR stage is also constrained to the hardware limit of 15 biquads per channel, with a live counter.

These dedicated modes require a valid license, but Hypex project export remains fully available without a license, exactly as before.

Another addition focuses on robustness of phase correction. After computing a phase-only FIR, LinFIR now evaluates its magnitude response and warns if it deviates from unity. In theory a phase correction filter should not modify magnitude. If it does, it usually indicates an overly aggressive configuration (too few taps, excessive Kaiser beta, or a correction range extending too low in frequency). The software now flags this situation and suggests practical adjustments.

Target curves can now be imported and exported from all correction windows (per-driver FIR, Auto-EQ, and global processing). The format is intentionally simple: a two-column text file with frequency and gain values, making it easy to save curves or edit them manually.

The microphone calibration manager also gained a small but useful feature: each calibration file can now be previewed directly in a plot window to inspect its frequency response.

Several internal improvements were made as well. Secondary windows are now automatically closed when a project is created or loaded, avoiding leftover windows from previous sessions. The clipping detection signal has been replaced with a deterministic pink-noise buffer designed to mimic the crest factor and spectral balance of real program material. Documentation was also updated to clarify the limitations of phase correction when using non-anechoic measurements.

Finally, a number of technical fixes improve measurement reliability and device handling, including sweep alignment before averaging, and safer sample-rate switching when changing input devices.

 

[Waveform Fidelity]

I'll import a set of target values and create an FIR filter in your tool and see how that compares with Marani AEQ design software

 

[Arnwald]

LinFIR 1.2.18 is now available.

This update focuses mainly on making phase-correction FIR filters more robust and predictable.

When designing a phase-only correction filter, the ideal result should leave the magnitude response untouched. In practice, depending on the correction range and tap count, numerical artifacts can appear and introduce magnitude deviations. LinFIR now includes an automatic guard that detects this situation and adjusts the correction bandwidth automatically.

If the magnitude deviation exceeds the user-defined tolerance, the software iteratively shifts the correction limits in 1/3-octave steps until the filter converges within tolerance. Each phase-correction filter now includes a “Guard Tolerance”parameter controlling the maximum allowed magnitude deviation (default 0.5 dB). A warning is shown only if the guard cannot converge after exhausting all iterations.

Several improvements were also made to the analysis graphs. Phase and group-delay plots now ignore ultrasonic data above 20 kHz when computing automatic axis bounds, preventing high-frequency noise from compressing the visible range. The phase graph also now fits its vertical scale directly to the data instead of forcing the 0° reference into view.

The graph toolbar was reorganized as well. Options are now grouped into three dropdown menus (“Graphs”, “Time Domain”, and “Phase Options”), reducing visual clutter while keeping controls accessible.

Finally, the update notification system was redesigned. Instead of appearing in the toolbar, updates are now shown as a small floating card in the bottom-right corner with install and dismiss actions, followed by a confirmation toast after installation.

 

[Arnwald]

LinFIR 1.2.19 / 1.2.20

A couple of small maintenance updates have been released, mainly focused on bug fixes and stability.

On Windows, an issue with ASIO measurements has been resolved where captures could abort with a false “timing reference too weak” warning. This was caused by stream startup latency not being properly accounted for.

Several fixes also target Hypex project mode, restoring expected behavior in areas such as FIR export, directivity sonogram access, phase display options, and report generation.

A few smaller issues were addressed as well, including phase graph scaling in edge cases (e.g. near-flat phase), and keyboard toggles that could leave graphs empty.

 

[Arnwald]

LinFIR 1.2.21 is now available.

This update brings a mix of stability fixes and a new feature aimed at improving real-world tonal balance.

A licensing issue has been fixed where activation could fail with a cryptic JSON parsing error. The root cause was an unexpected server response (Cloudflare, rate limiting, etc.) not being handled properly. LinFIR now checks HTTP responses correctly and returns clear error messages instead of crashing.

On macOS, full-screen behavior has also been improved. Secondary windows (filters, IR management, etc.) now behave as expected and no longer open as tabs or create rendering issues.

For licensed users, this version introduces a Listening Window-based correction workflow.

You can now use the Listening Window (defined as the spatial average of measurements within ±30° horizontally and ±10° vertically) as the reference for both global Auto EQ and FIR magnitude correction, instead of relying solely on the on-axis response.

The idea is straightforward: rather than optimizing EQ for a single axis, you can now target what is actually heard across a small listening area, which generally leads to a more balanced and natural tonal result.

There is one important caveat: with drivers that become strongly directive at high frequencies (increasing directivity index), the Listening Window will naturally roll off in the top end. This is expected behavior and should be compensated through the target curve rather than “corrected away” blindly.

A few smaller improvements were also made, including resizable UI elements for better usability.

 

[Arnwald]

To illustrate, here I have the FIR filter set on "On-axis":

When using the listening window with a flat targe, you get a rising response:

It can be corrected with a simple target curve :

 

[Waveform Fidelity]

Hi Arnwald

Very nice work.

Yesterday I imported a sample driver frequency response and defined a bandpass filter similar to what I use in Marani AEQ, but I could not find a way to adjust the phase. Is that part working? How do Invoke phase equalization as a correcting response?

 

[ShadowBoxer]

Fyi, I can't seem to get this About-link to open from within the Win app (there is a msg that flashes for a nanosecond as it tries to hand off to a browser).

I'm trying to find out paid-license price. (Update: $149 pounds.)

 

[829]

Hi @Arnwald, looks promising as far as I have read through all the replies! But what instantly stopped me from proceeding is the requirement to go through the Windows Store. I am sure you have your reasons for that but please consider offering a downloadable executable file which can be verified through digital signature and hash for authenticity. If I have to use Windows, I‘d never encourage the dependency on such more and more locked-down platform.

Needless to say, I‘d welcome a Linux version. Is the licence cross-platform compatible, i.e., can somebody who bought it for macOS also use it on Windows and can it be used completely offline?

Also it‘s a bit hard to find the licence cost; one has to click on "Buy a license" on your website and check the bottom of the payment page.

 

[Arnwald]

Hi Arnwald

Very nice work.

Yesterday I imported a sample driver frequency response and defined a bandpass filter similar to what I use in Marani AEQ, but I could not find a way to adjust the phase. Is that part working? How do Invoke phase equalization as a correcting response?

Hi,

The phase correction is automated. You can find it under the FIR correction filter:

Fyi, I can't seem to get this About-link to open from within the Win app (there is a msg that flashes for a nanosecond as it tries to hand off to a browser).

I'm trying to find out paid-license price. (Update: $149 pounds.)

I'll take a look to see what's going on, thanks for the info.

Hi @Arnwald, looks promising as far as I have read through all the replies! But what instantly stopped me from proceeding is the requirement to go through the Windows Store. I am sure you have your reasons for that but please consider offering a downloadable executable file which can be verified through digital signature and hash for authenticity. If I have to use Windows, I‘d never encourage the dependency on such more and more locked-down platform.

Needless to say, I‘d welcome a Linux version. Is the licence cross-platform compatible, i.e., can somebody who bought it for macOS also use it on Windows and can it be used completely offline?

Also it‘s a bit hard to find the licence cost; one has to click on "Buy a license" on your website and check the bottom of the payment page.

That’s a fair point, and I understand the concern.

The reason I currently distribute LinFIR through the Microsoft Store is mainly related to code signing and user trust. On Windows, distributing a standalone executable without proper signing triggers very aggressive security warnings (SmartScreen), which essentially tells users that the application may be unsafe.

Obtaining and maintaining a proper code signing certificate outside of the Store is unfortunately quite heavy for a small independent developer:

• certificates are expensive and must be renewed yearly
• some providers still require hardware tokens (USB keys)
• reputation-based signing (SmartScreen) takes time to build and can still flag new releases

Because of that, the Store currently provides the most reliable way to ensure a smooth installation experience for users without scary warnings.
That said, I understand the desire for a standalone executable, and I may revisit this in the future if I find a practical solution.

Regarding your other questions:

• The license is cross-platform (Mac OS and Windows)
• The app works offline, but activation requires an internet connection
• A Linux version is in the works (there’s clearly demand for it) but I’m developing LinFIR alongside a full-time job, so progress depends on the time I can allocate

I'll put the cost directly on the website, I was certain that it was there... I guess I forgot to save the changes in Wordpress.

 

[829]

Thanks for the explanation. Yes, SmartScreen can be quite annoying and does promote dependency from its platform; for the better and worse of it.

I‘m not suggesting to cancel your current Windows Store offering; but you could offer downloads which are verifiable for authenticity similarly to how Tor Browser or Qubes OS describe the process to their users additionally. PGP = free of charge | X.509 can always be added later. (Plus SHA256 / SHA512 sums, for separate file integrity checks.)

 

[Arnwald]

Thanks for the suggestion, that approach makes sense for projects like Tor or Qubes.

In my case, the main concern is user experience. LinFIR is not aimed at a highly technical audience, and I don’t want to introduce multiple distribution channels where one requires manual verification steps while still triggering SmartScreen warnings.

That would likely confuse less experienced users and create more friction rather than solving the problem.

The goal is to keep installation as simple and safe as possible, which is why I’m currently sticking with the Windows Store.

 

[Waveform Fidelity]

Hi Arnwald

Under phase correction, do you force everything to zero phase? Rather than a constant phase angle?

Sometime the number of taps, limits how much phase correction can be made. At low frequencies both amplitude and phase need many taps to get the desired EQ curve.

I’ll find some time this week to play with it a bit more.

Best regards

 

[Arnwald]

Hi Waveform,

The phase correction targets zero excess phase, i.e. zero phase once the bulk delay (time of flight) has been removed. This is equivalent to a flat group delay, and results in a symmetric impulse response.

I can't go into the details of the algorithm itself, but the short answer to your question is: yes, the target is zero phase, not a constant non-zero angle.
A modulo 2π offset can appear when the phase is unwrapped, this is due to the fact that the individual phase curves are aligned on the graph for better comparison.

Regarding taps and low frequencies, this is expected behaviour. Group delay is the derivative of phase with respect to frequency, so a given phase rotation at low frequencies corresponds to a much larger time shift than the same rotation at high frequencies. More taps are therefore needed to correct low-frequency phase. This is covered in the documentation:

Driver Processing - LinFIR Documentation

demaudio.com

Driver Processing - LinFIR Documentation

demaudio.com

 

[Waveform Fidelity]

Thanks very much - I’ll take a closer look.

If the number of taps is a user defined constraint, what happens to the correcting filter phase response (e.g at low frequencies) - does the zero phase response blend in to the drivers phase response, when the processing runs out of taps?

 

[Arnwald]

Thanks very much - I’ll take a closer look.

If the number of taps is a user defined constraint, what happens to the correcting filter phase response (e.g at low frequencies) - does the zero phase response blend in to the drivers phase response, when the processing runs out of taps?

Indeed.

In fact, there is two possible behaviours:
- As is, it will adjust the lower frequency to fit the phase correction filter requirements (i.e. to correct phase without introducing magnitude artefacts)
- Or adjust the guard tolerance parameter (in dB): you will gain a bit of correction in the low frequencies at the expense of non-unitarity gain in magnitude (it can introduce attenuation or ripples). Basically, the filter becomes too long for the allocated taps and gets truncated.

Be aware that phase correction must be done on clean anechoic measurements. In Room Calibration mode, the phase is polluted by reflections and room modes, and at least 5 or 6 measurements may be needed to average and smooth out everything. Even so, I strongly advise against room phase correction. Given the fact that phase distortion is not really audible, it can do more harm than good. Phase linearisation is an interesting tool when designing a loudspeaker: it helps with driver alignement and crossover summation.

I explained this in details in this part of the documentation:

Driver Processing - LinFIR Documentation

demaudio.com