TOPIC:

I recently bought a MiniDSP 2x4HD and wanted to use it on my Linux box, so I inspected the way the plugin was communicating with the device. After configuring it using OSX, I've managed to write a small utility to send the right USB/HID commands to perform some basic actions (control gain/mute/source).

It can be installed with npm - make sure to grab a recent version of node (6.x)

Then you can do a quick check to see if audio is coming through:


It's possible to change pretty much any configuration parameter but because the plugin doesn't read back from the device, you can't really mix different programs to configure the same box. Volume/Mute seems to be the exception to this - most probably due to the physical volume knobs changing the same settings.

This could also be used on embedded platforms like raspberry pi or others - so it could switch the input to USB before playing audio.

Let me know if you find it useful

Code and instructions are on github.com/mrene/node-minidsp

@ Mrene

heheh.. This is nice... It sounds like you got busy... This is the first time we got someone going to that level.. It's neat!
We don't have Linux support for our plugin unfortunately (we're already overloaded doing Win x 6 OS versions, Mac x 6 OS versions) but we love to see that level of creativity. Hoping your 2x4HD is rocking and have fun!

DevTeam

It works quite well - only weird thing is that channel 3 and 4 were swapped out (the physical port for 4 has the software output channel 3, and vice-versa).

Stumbling upon the iOS application I added a "proxy command" so it relays port 5333 to USB just like the application does - this makes the application work for remote control. I can even use the plugin on a different machine altogether by locally forwarding :5333 to the box which runs the proxy before starting the plugin (it tries to connect before launching the helper).

The plugin itself runs under the (now deprecated) linux air runtime, but it doesn't attempt to connect locally because it doesn't know what to do under Linux. If it were to, let's say, ignore OS-specific rules and try to connect anyways - it could work without too many changes I suspect that's what the "home theater" plugins must do, since they accept connections over the network.

@ mrene

You're getting quite close..
Some hints: the minidsp.exe bridge under Win is what translate IP to USB commands basically (Air isn't USB friendly). I'd expect that Linux would do similar.

devTeam

Nice thanks!

Q: Do you know how to read and monitor also the output channel signals?

PS: I had to revert/install an older node version to make it work today:
"nvm use 8.17.0"

Hey,

That's surprising timing, I'm about to release a rewrite of this built using rust instead, so there are pre-built binaries for different platforms. It supports a lot more features (I'm almost covering everything the plugin does (well minus the UI and filter design I guess )) .

The main program output will show you the input and output device levels.
Check out:
github.com/mrene/minidsp-rs
github.com/mrene/minidsp-rs/releases

Very cool, I'll give it a shot! Never heard about rust so far, I just looked it up.

Have to find our if I could make use of this as a tool callable from python some how, then I could add a few nice graphical visuals

Somebody did port some of the wire protocol to python: github.com/markubiak/python3-minidsp

There are some caveats with the way the underlying hid lib works though, since the device sometimes sends unsolicited events (for example, to indicate when the volume was changed through the remote). It should work great for most cases though, just throw in some padding for unexpected messages that aren't the response you're looking for.

I located the output level read command in you rust code and ported/added it to the python lib hack!

And then reworked my old home build DSP monitoring tools to read the minidsp Very cool!!!
I'll clean it up a bit and put on githut then also... may add a nice GUI to do the basic controls also.

Nice!

There is a way to read both the input and output levels simultaneously, if you're going to be hammering the device with commands it could give you a better refresh rate.
The 0x14 command reads a series of floats, it's syntax is 0x14 [ addr u16 ] [len u8]. The input levels are at 0x44 and the output levels at 0x4a (as you've discovered). If you set the length to 0xA you'll get both in the same response. (beware that the USB HID descriptor has a fixed length of 64 bytes per frame, so you can't read too much.

Other nice thing to know if you're poking around the protocol: if you set RUST_LOG=trace you'll get debug data including the frame's hex dumps.

There's alsothat sends a command and shows the parsed response (this miiiight be only on the dev branch, I'll make a release this weekend)

Example: (I use --tcp because I run the server component somewhere else)
The first two floats are the input levels, the last 4 are the output ones.

Not what I expected, but I patched the result together:

I first tried to read on 6 values, but received only 0's after In0,1, then reading 0x0a as you said:
command = [0x14, 0x00, 0x44, 0x0a]

And received this:
14, 00, 44, c4, d1, 91, c2, c2, fb, 5e, c2, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 5b, b4, a4, c2, c8, fc, 91, c2, d2, 92, 60, c2, 7b, fd, 91, c2

And the Out gains far back, so I patched that together to get floats, seam to work fine:
(-72.90969848632812, -55.74585723876953, -82.35225677490234, -72.99371337890625, -56.14337921142578, -72.99507904052734)

... I can imagine it's for compatibility reasons when having more than 2 inputs ....

PS: I could actually use a 3rd input as I compute and flatten the curve for my RiPol sub woofer as I ideally mix L+R+LFE togther and process, now only using R+LFE, most cases fine as sub 70Hz likely is non directional anyways. Oh well...

---

def getLevels(self):
# get input and output levels on the DSP right now.
# adapted from github.com/mrene/minidsp-rs
command = [0x14, 0x00, 0x44, 0x0a]
resp = self._transport.write(command)
# Validity checking
print (", ".join("{:02x}".format(num) for num in resp))

if resp[:3] != [0x14, 0x00, 0x44]:
raise RuntimeError("Received unexpected response: " + str(resp))
# current levels are in the response in two 32bit low-endian floats
# In0,1 at index 3-7 and 8-11 inclusive; so unpack two nums...
# Out0,1,2,3 at index 27..43 -- interestingly so!
# no rounding or anything, so if sending down a json wire or something
# you might want to trim
db = struct.unpack("<ff", bytes(resp[3:11]))
db = db + struct.unpack("<ffff", bytes(resp[27:43]))
return db

the first hack of a Linux Pythin/Gtk based MINI DSP Control and Monitor is here:

github.com/pyzahl/miniDSP2x4HD-PyGI

just fire up ./minidsp_monitor.py

pyzahl20 wrote:

... I can imagine it's for compatibility reasons when having more than 2 inputs ....

Actually I just figured out they are the output channels' compressor levels! Explains why there was 4 floats in a row in a 2x4HD

Hi,

Just wanted to say thank you for minidsp-rs and confirm that
it appears to be working well with my miniDSP SHD.

I was able to connect the SHD plugin to minidsp-rs running
on a RPi4, which was in turn connected via USB to the SHD.

The "auto" feature of the SHD plugin did not discover the
minidsp-rs service but all worked when I manually entered
the RPi4's IP address.

I did not need to modify anything. Let me know if you want
me to experiment with any features. If reasonably simple,
I'd be glad to help.

Thanks
Feathers

Nice! Good to hear it's working with other devices.

Using it with the plugin is the "easy part" of supporting devices, since there's a common denominator of how devices communicate. Are you able to create an issue on the github repo and include the following:

- Exact model of your device
- Output of(so I can identify the vendor and product id)
- Output of(particularily, the first few lines where the dsp version and hardware id are reported)
- An example xml configuration file (you can save it from the plugin). It doesn't have to be empty, it includes a lot of adresses for all the different components.

(Since you are running the server component, you may have to runinstead, since the device will be in use by the service)

There is already an issue opened for the 4x10HD and OpenDRC DA-8, with that info I'll be able to add the SHD to the list once I get the time to finish integrating them.