The miniDSP "Write-Only" Problem

This article is intended as a supplement to the FAQ. It explains one specific cause of the frequently encountered problem of final validation measurements not agreeing with MSO's response predictions.

The miniDSP Software Display May Not Accurately Reflect the Device State

If you use any software for configuring the state of a miniDSP device other than what's provided by miniDSP, and subsequently go back to the miniDSP software for further configuration, there is no guarantee that the information displayed in the miniDSP software accurately reflects the actual state of the device. The reason for this is that the complete state of the miniDSP device cannot be read by any external software.

Only Trivial Information Can Be Read From a miniDSP Device

For all displayed information of a hypothetical software that configures the state of a miniDSP device to be accurate under all possible circumstances, such software would need to be able to read the entire state of the miniDSP device into memory and set itself up accordingly when starting up. But this is not possible with current miniDSP hardware. Only the master volume, master mute, input type, and active config slot can be read.

Since configuration software cannot read the full state of the device, the miniDSP software does the best it can, saving the last information it wrote to the device and displaying that as if that were the actual device state. But if any other software has written state information to the device prior to the miniDSP software having been run, the miniDSP software may not "know" that. It can only display the last information it wrote to the device, rather than the state information that's actually in the device.

The miniDSP software may be able to detect that changes have been made by other software, but it cannot "know" what those changes were, and it's not clear whether it can detect such changes under all circumstances. If you see a warning message to the effect that the device state has changed since the last time the miniDSP software was run, don't ignore the message. It's a sign that you should invoke the reset function described below.

The ezbeq Software Documentation Warns About This

One such third-party software that can be used to configure a miniDSP device is ezbeq. There is a section of the ezbeq software documentation called Suggested interaction of ezbeq and official MiniDSP plugin that describes the situation. You should read it and follow its directions carefully. When using ezbeq in conjunction with MSO, always use ezbeq last, after all the channel biquads, delays, and gains determined by MSO have been loaded.

If In Doubt, Use the miniDSP Reset Function

A given miniDSP configuration (or all its configurations) can be reset to a known state using the miniDSP reset functionality. See the reset topic in the miniDSP documentation for how to use it. Once a reset is performed, the displayed miniDSP software state will match the device state.

It may also make sense to do such a reset before making the initial measurements for MSO. See the measurement section of the reference manual for details.

The miniDSP Software Should be Upgraded to the Newer Device Console

If you are still using the old miniDSP "plug-in" software, you should upgrade it to the newer Device Console. This upgrade also involves a firmware update. Some users have reported that usage of the new firmware fixed their correlation problem between MSO's predicted response and the final measured validation response.

In addition, the newer firmware and software is reported to not set the crossover back to its former default state of having 1 kHz high-pass filters in two of the four channels and low-pass filters in the other two. The majority of miniDSP 2x4 HD users use the device for sub equalization and integration, not the "active crossover" role implied by the presence of these high-pass and low-pass filters. Bypassing the crossover by default is reason enough by itself to do the upgrade.