mrene/minidsp-rs

MiniDSP Controller

MiniDSP Controller

minidsp-rs is an alternative control software for certain MiniDSP products. It exposes most (if not all) of the available configuration parameters in a command line package, with an optional HTTP API in order to integrate with custom DIY audio projects. It can run on a variety of systems with a minimal memory footprint.

Installation

Pre-built packages and binaries are available in the project's releases section.

Debian (.deb) packages are available for:

• armhf: Tested on raspbian (Raspberry PI, including the rpi0)
• x86_64 Debian / Ubuntu variants

Single binary builds are also provided for common operating systems:

• Linux: minidsp.x86_64-unknown-linux-gnu.tar.gz
• MacOS: minidsp.x86_64-apple-darwin.tar.gz
• Windows: minidsp.x86_64-pc-windows-msvc.zip

Building from source

This is only required if you want to make changes to minidsp-rs. If you're just trying to control your device, use one of the pre-built packages

If you don't have rust setup, the quickest way to get started is with rustup. This is preferred over install rust via your distro's package manager because these are often out of date and will have issues compiling recent code.

cargo build --release --bin minidsp
# The binary will then available as target/release/minidsp

# If you want to build a debian package
cargo install cargo-deb
cargo deb
# Then look under target/debian/

Usage

See the complete documentation for more examples.

Running the command without any parameters will return a status summary, in this form:

$ minidsp 
MasterStatus { preset: 0, source: Toslink, volume: Gain(-8.0), mute: false, dirac: false }
Input levels: -61.6, -57.9
Output levels: -67.9, -71.6, -120.0, -120.0

Useful commands

# Set input source to toslink
minidsp source toslink

# Set master volume to -30dB
minidsp gain -- -30

# Activate the 2nd configuration setting (indexing starts at 0)
minidsp config 1

Supported devices

These device support the full feature set. See the documentation for a more complete list.

• miniDSP 2x4HD
• miniDSP Flex
• DDRC-24
• DDRC-88A/D
• miniSHARC series
• miniDSP 2x8/8x8/4x10/10x10
• nanoDIGI 2x8
• SHD series
• C-DSP 8x12 v2

minidsp-rs's Issues

PEQ input import, clear, and bypass do not work

PEQ input import, clear, and bypass seem to work (no errors), but do not actually apply.

Tried 2 methods for each of these...

1. minidsp app on Win10 connected directly to MiniDSP 2x4HD via USB
2. minidsp app on Linux using remote (--tcp ip:5333) to minidsp app on Win10 (#1 above)

Attempted following commands:
minidsp input 0 peq all clear
minidsp input 0 peq all bypass on (or off)
minidsp input 0 peq all import
minidsp input 1 peq all clear
minidsp input 1 peq all bypass on (or off)
minidsp input 1 peq all import

The server side shows the config (example here, for bypass):
Sent: WriteBiquadBypass { addr: 20b7, value: true }
Recv: Ack
Recv: Ack
Sent: WriteBiquadBypass { addr: 20b2, value: true }
Recv: Ack
Recv: Ack
Sent: WriteBiquadBypass { addr: 20ad, value: true }
Recv: Ack
Recv: Ack
Sent: WriteBiquadBypass { addr: 20a8, value: true }
Recv: Ack
Recv: Ack
Sent: WriteBiquadBypass { addr: 20a3, value: true }
Recv: Ack
Sent: WriteBiquadBypass { addr: 209e, value: true }
Recv: Ack
Recv: Ack
Recv: Ack
Sent: WriteBiquadBypass { addr: 2099, value: true }
Recv: Ack
Recv: Ack
Sent: WriteBiquadBypass { addr: 2094, value: true }
Recv: Ack
Recv: Ack
Sent: WriteBiquadBypass { addr: 208f, value: true }
Recv: Recv: AckAck

Sent: WriteBiquadBypass { addr: 208a, value: true }
Recv: Ack
Recv: Ack

Change windows archive format to zip

Releases are published using tarballs, which is cumbersome for Windows users, changing this to a zip file would make it easier to install.

FIR, crossover and compressor support

Add cli commands to be able to:

• Configure an FIR filter on each output channel while setting the number of active taps
  • Read coefficients from a wav file (ensure it has the right sampling rate)
• Control compressor parameters on output channels
• Set crossover biquads (could use a similar syntax to PEQ since we don't support designing the filters yet)

Apply PEQ from REW's text format

Apply PEQ from REW's text format
Add all target to input/out peq commands to bypass all eqs at once

Not showing in the app after bootup until service is restarted

MiniDSP device not showing in the app after bootup. Have to restart the service or add a sleep timer.

Setup:
minidsp-rs installed on volumio 3. Volumio 3 is running on raspberry pi zero 2 w using a usb dongle.
/etc/minidsp/config.toml has
bind_address = "0.0.0.0:5380"
bind_address = "0.0.0.0:5333"
advertise = { ip = "192.168.1.20", name="Volumio" }

where 192.168.1.20 is the DHCP reservation for the raspberry pi 2 w.

After bootup:
-bash-5.0# systemctl status minidsp
minidsp.service - MiniDSP Server
Loaded: loaded (/lib/systemd/system/minidsp.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-12-12 08:49:49 UTC; 1min 43s ago

But, minidsp device does not show up in the app.

If the service is restarted with:
systemctl restart minidsp

minidsp device does show up in the app.

Changing /lib/systemd/system/minidsp.service to the following does not help
[Unit]
After=network-online.target
Wants=network-online.target

Had to add
[Service]
ExecStartPre=/bin/sleep 30

Is there any other way to solve the device not showing in the app without a sleep pre service start?

Cargo install fails on Pi3

After installing Cargo using apt-get on a fresh install of Raspbian OS, I'm unable to complete an install of minidsp using cargo install minidsp

Here's my output:

    Updating crates.io index
  Downloaded minidsp v0.0.3
  Downloaded 1 crate (67.5 KB) in 1.89s
  Installing minidsp v0.0.3
  Downloaded futures-sink v0.3.10
  Downloaded futures-io v0.3.10
  Downloaded futures v0.3.10
  Downloaded tokio-stream v0.1.2
  Downloaded futures-util v0.3.10
  Downloaded futures-core v0.3.10
  Downloaded futures-executor v0.3.10
  Downloaded futures-channel v0.3.10
  Downloaded futures-task v0.3.10
  Downloaded futures-macro v0.3.10
   Compiling proc-macro2 v1.0.24
   Compiling unicode-xid v0.2.1
   Compiling syn v1.0.58
   Compiling libc v0.2.82
   Compiling autocfg v1.0.1
   Compiling memchr v2.3.4
   Compiling cfg-if v1.0.0
   Compiling version_check v0.9.2
   Compiling log v0.4.13
   Compiling futures-core v0.3.10
   Compiling once_cell v1.5.2
   Compiling proc-macro-hack v0.5.19
   Compiling pin-project-lite v0.2.4
   Compiling lazy_static v1.4.0
   Compiling cfg-if v0.1.10
   Compiling futures-sink v0.3.10
   Compiling proc-macro-nested v0.1.6
   Compiling scopeguard v1.1.0
   Compiling smallvec v1.6.1
   Compiling futures-io v0.3.10
   Compiling adler v0.2.3
   Compiling gimli v0.23.0
   Compiling slab v0.4.2
   Compiling bytes v1.0.1
   Compiling rustc-demangle v0.1.18
   Compiling jetscii v0.4.4
   Compiling regex-syntax v0.6.22
   Compiling unicode-segmentation v1.7.1
   Compiling object v0.22.0
   Compiling cc v1.0.66
   Compiling bitflags v1.2.1
   Compiling pkg-config v0.3.19
   Compiling pin-utils v0.1.0
   Compiling unicode-width v0.1.8
   Compiling termcolor v1.1.2
   Compiling anyhow v1.0.38
   Compiling hashbrown v0.9.1
   Compiling vec_map v0.8.2
   Compiling humantime v2.0.1
   Compiling termcolor v0.3.6
   Compiling strsim v0.10.0
   Compiling xmlparser v0.13.3
   Compiling riff v1.0.1
error[E0599]: no associated item named `MAX` found for type `u32` in the current scope
  --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/riff-1.0.1/src/lib.rs:97:37
   |
97 |         if data.len() as u64 > u32::MAX as u64 {
   |                                     ^^^ associated item not found in `u32`
   |
help: you are looking for the module in `std`, not the primitive type
   |
97 |         if data.len() as u64 > std::u32::MAX as u64 {
   |                                ^^^^^^^^^^^^^

error[E0599]: no associated item named `MAX` found for type `u32` in the current scope
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/riff-1.0.1/src/lib.rs:123:29
    |
123 |         if total_len > u32::MAX as u64 {
    |                             ^^^ associated item not found in `u32`
    |
help: you are looking for the module in `std`, not the primitive type
    |
123 |         if total_len > std::u32::MAX as u64 {
    |                        ^^^^^^^^^^^^^

error[E0599]: no associated item named `MAX` found for type `u32` in the current scope
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/riff-1.0.1/src/lib.rs:145:29
    |
145 |         if total_len > u32::MAX as u64 {
    |                             ^^^ associated item not found in `u32`
    |
help: you are looking for the module in `std`, not the primitive type
    |
145 |         if total_len > std::u32::MAX as u64 {
    |                        ^^^^^^^^^^^^^

error: aborting due to 3 previous errors

For more information about this error, try `rustc --explain E0599`.
error: could not compile `riff`.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `minidsp v0.0.3`, intermediate artifacts can be found at `/tmp/cargo-installbAOOuo`

Caused by:
  build failed

I have that referenced folder if that's of any use?

MiniDSP 2x4 support?

Hi!

I'm just wondering: Is there any special reason why the 2x4 isn't supported yet?
Can I help somehow as someone who has one but has too little programming experience?

'lsusb -v' output

illegal hardware instruction error with

Hi!
Very grateful for your application.
I'm currently trying to create a Stream Deck plugin that talks to the HTTP API on minidspd, but I'm often faced with the daemon crashing with the error zsh: illegal hardware instruction .
Is this a known issue?
I'm running minidsp-daemon 0.1.4

Many thanks!
Alex

EzBeq.clearSlot failed, HTTP status 500 error with 0.1.8

I downloaded 0.1.8 and now am getting a "EzBeq.clearSlot failed, HTTP status 500" every time I try to make a change using EZBeq. SSH session with a "minidsp" command shows my 2x4HD as connected. I even just reset my Pi and did a clean install wondering if something was messed up on it. But I am still seeing that error even after a complete new installation of Raspian, minidsp-rs and EZBeq.

On my SSH session I see this info at the end of the process..

"raise ProcessExecutionError(

plumbum.commands.processes.ProcessExecutionError: Unexpected exit code: 1

Command line: | /usr/bin/minidsp -f /tmp/tmpw3kolc2o

Stderr: | While executing: input 0 peq 0 bypass off

| error: The argument '[VALUE]' requires 0 values, but 1 was provided

|

| Usage: minidsp input peq bypass [VALUE]

|

| For more information try '--help'

|

| Error: Command failure
"

Not sure if there is any information in that data that can point to what is occurring? I downgraded back to v0.1.7 and EZBeq started working just fine again. Not sure if I missed something, but .8 doesn't work for me.

Generate device definitions based on xml configs

beqdesigner has xml config test fixtures for different product versions

Device configs can be generated based on its contents, since it contain all the necessary addresses.

Feature request: master mute toggle

Thank a lot for the awesome project! I use it on a daily basis to control my home stereo setup.

For similar reasons the relative gain feature was introduced I would like to be able to toggle the master mute setting. I have a rotary encoder based volume knob that emulates a keyboard. I would like to be able to toggle the master mute regardless of the current state by pressing the knob.

cargo.lock out of date

The Cargo.lock in release 0.1.9 is out of date. https://github.com/mrene/minidsp-rs/blob/v0.1.9/Cargo.lock#L566

I'm building a Nix package for minidsp-rs, and it is complaining about this. I can patch around it, but wanted to let you know that it got missed in the latest release. Thanks!

Intermittent "Error: A malformed packet was received"

I have minidsp running in server mode on an rpi connected via USB to the minidsp 2x4.
I'm able to communicate with the minidsp over tcp from a windows 10 machine using: minidsp --tcp 192.168.86.40:5333
Server is 192.168.86.40, client is 192.168.86.54.

When attempting to clear or bypass all filters for an input I get the message: Error: A malformed packet was received

This is the command I'm sending: minidsp --tcp 192.168.86.40:5333 input 1 peq all bypass on

If I use minidsp --tcp 192.168.86.40:5333 input 1 peq all clear I get an error every time.

Here's the log from the server

Working call:

New connection: 192.168.86.54:50768 Sent: WriteBiquadBypass { addr: 20b7, value: true } (0x20b7 | 8375) <> PEQ_2_10 Recv: Ack Recv: Ack Sent: WriteBiquadBypass { addr: 20b2, value: true } (0x20b2 | 8370) <> PEQ_2_9 Recv: Ack Recv: Ack Sent: WriteBiquadBypass { addr: 20ad, value: true } (0x20ad | 8365) <> PEQ_2_8 Recv: Ack Recv: Ack Sent: WriteBiquadBypass { addr: 20a8, value: true } (0x20a8 | 8360) <> PEQ_2_7 Recv: Ack Recv: Ack Sent: WriteBiquadBypass { addr: 20a3, value: true } (0x20a3 | 8355) <> PEQ_2_6 Recv: Ack Recv: Ack Sent: WriteBiquadBypass { addr: 209e, value: true } (0x209e | 8350) <> PEQ_2_5 Recv: Ack Recv: Ack Sent: WriteBiquadBypass { addr: 2099, value: true } (0x2099 | 8345) <> PEQ_2_4 Recv: Ack Recv: Ack Sent: WriteBiquadBypass { addr: 2094, value: true } (0x2094 | 8340) <> PEQ_2_3 Recv: Ack Recv: Ack Sent: WriteBiquadBypass { addr: 208f, value: true } (0x208f | 8335) <> PEQ_2_2 Recv: Ack Recv: Ack Sent: WriteBiquadBypass { addr: 208a, value: true } (0x208a | 8330) <> PEQ_2_1 Recv: Ack Recv: Ack Closed: 192.168.86.54:50768

Response that resulted in an error on the client:

New connection: 192.168.86.54:50772 Sent: WriteBiquadBypass { addr: 20b7, value: true } (0x20b7 | 8375) <> PEQ_2_10 Recv: Ack Recv: Ack Sent: WriteBiquadBypass { addr: 20b2, value: true } (0x20b2 | 8370) <> PEQ_2_9 Recv: Recv: Ack Ack Sent: WriteBiquadBypass { addr: 20ad, value: true } (0x20ad | 8365) <> PEQ_2_8 Recv: Ack Recv: Ack Closed: 192.168.86.54:50772
Also, two issues in your readme.
In the input PEQ section the command examples have output listed instead of input, and in both input and output sections your last peq example says preq instead of peq.

ws only updates when cli executes

I have a client listening to the websocket on ws://localhost/devices/0?levels=true via /tmp/minidsp.sock and a separate shell open

execution of minidsp in the shell immediately produces {"master":{"preset":1,"source":"Usb","volume":-4.0,"mute":false}} on the websocket

if I then do

$ minidsp -v gain -- -5                                                                                                                                                                              
 
Sent: ReadHardwareId 
Recv: HardwareId { payload: [01, 09, 0a] }
Sent: ReadMemory { addr: ffa1, size: 01 } 
Recv: MemoryData(MemoryView { base: ffa1, data: [64] })
Sent: ReadMemory { addr: fffc, size: 02 } 
Recv: MemoryData(MemoryView { base: fffc, data: [ff, ff] })
Sent: SetVolume { value: Gain(-5.0) } 
Recv: Ack

nothing is received via the ws

then

$ minidsp
MasterStatus { preset: 1, source: Usb, volume: Gain(-5.0), mute: false, dirac: false }
Input levels: -131.4, -131.4
Output levels: -128.4, -128.4, -120.0, -128.4

shows the command was accepted and gain updated

and the ws receives

{"master":{"preset":1,"source":"Usb","volume":-5.0,"mute":false}}

so it seems like the ws is not updating as expected

USB transport resets if a command is sent right after a config preset change

SHD support

Hi,

Here is the information you requested for minidsp-rs connected
to a miniDSP SHD. This is a SHD (not SHD Studio or Power)
purchased about August or September of 2019. The host connected
to the SHD and running minidsp-rs is a RPi 4B 8GB running the
32 bit version of RPi OS Buster. Versions of the miniDSP plugin
for Windows and SHD firmware are 1.15 and 1.29, respectively.

Attached are the saved configuration XML file from the Windows
plugin and zipped directory tree. The directory tree has the output
produced by the various commands you requested plus a few extra.
Also included is the content yielded by cating the various files
located in and below /proc/asound/SHD/.

Let me know if you need any additional information. Thanks
again for creating minidsp-rs.

Cheers
Feathers

Configuration.xml.zip
SHD.zip

Build debian package with cargo-deb

Create packages for:

• raspbian
• debian buster
• ubuntu 20.04

Include systemd unit file so the server component is automatically started

ERROR minidsp::transport::multiplexer] recv loop exit: ParseError(EmptyPacket)

I have a pi3 running minidsp-rs connected to a minidsp 2x4HD. It runs for days/weeks without issue and then I start getting the following error:

pi@singlesubs:~ $ minidsp [2022-12-20T19:55:24.732Z ERROR minidsp::transport::multiplexer] recv loop exit: ParseError(EmptyPacket) [2022-12-20T19:55:24.732Z ERROR minidsp::transport::multiplexer] recv loop exit: ParseError(EmptyPacket) Error: A device request timed out

I have a second pi connected to a different minidsp 2x4HD and that's working fine. I suspect it's a minidsp issue but I wanted to flag it here just in case it's useful.

I saw another post where the user had the same issue and you asked him to run a specific command. I've followed that and it looks like minidsp-rs can see the minidsp.

pi@singlesubs:~ $ minidsp -vvv probe [0.000s] Sent: [31] [0.000s] Sent: ReadHardwareId [0.005s] Recv: [31, 01, 11, 0a] [0.005s] Recv: HardwareId(HardwareId { fw_major: 01, fw_minor: 11, hw_id: 0a }) [0.006s] Sent: [05, ff, a1, 01] [0.006s] Sent: ReadMemory { addr: ffa1, size: 01 } [0.008s] Recv: [05, ff, a1, 64] [0.009s] Recv: MemoryData(MemoryView { base: ffa1, data: [64] }) [0.010s] Sent: [05, ff, fe, 02] [0.010s] Sent: ReadMemory { addr: fffe, size: 02 } [0.012s] Recv: [05, ff, fe, 4f, c7] [0.013s] Recv: MemoryData(MemoryView { base: fffe, data: [4f, c7] }) 0: Found 2x4HD with serial 920423 at ws://localhost/devices/0/ws [hw_id: 10, dsp_version: 100]

Is there anything further I can do to confirm where the issue lies? I've rebooted the pi and the issue persists. I can reboot the minidsp as well but I thought it might be useful to investigate while the error is happening.

Config Change Detection

I am using EZBEQ and when I change configurations using the remote on the mini DSP device this change is not detected. When I change volume using the mini DSP remote this change is detected. I am using a DDRC-88A, if that is a factor.

Thank you.

Provide machine readable status output

current output is easy to read but fiddly to parse, an option to format this output in some way would be useful e.g.

minidsp -o json

would provide the same output but as a json document

DDRC-24 is not correctly recognized - v0.1.0

Hi,

Just updated minidsp-rs to the newest version. I can confirm that Source change via remote triggers update events now but device is still recognized as 2x4HD instead of DDRC-24;

$ minidsp probe
Found 2x4HD with serial 965535 at usb:0001%3A0004%3A04?vid=2752&pid=0044 [hw_id: 10, dsp_version: 101]

Readings in verbose mode (connected via official plugin app):

$ minidsp -v server
Sent: ReadHardwareId
Recv: HardwareId { payload: [01, 0b, 0a] }
Sent: ReadMemory { addr: ffa1, size: 01 }
Recv: MemoryData(MemoryView { base: ffa1, data: [65] })
Sent: ReadMemory { addr: fffc, size: 02 }
Recv: MemoryData(MemoryView { base: fffc, data: [ff, ff] })
Sent: ReadMemory { addr: ffa1, size: 01 }
Recv: MemoryData(MemoryView { base: ffa1, data: [65] })
Sent: ReadHardwareId
Recv: HardwareId { payload: [01, 0b, 0a] }
Sent: ReadMemory { addr: ffc8, size: 10 }
Recv: MemoryData(MemoryView { base: ffc8, data: [05, dc, a6, 77, 01, 98, 53, 39, 01, 81, 5f, 42, 02, 10, 3a, 3b] })
Sent: ReadMemory { addr: ffd9, size: 01 }
Recv: MemoryData(MemoryView { base: ffd9, data: [01] })
Sent: ReadMemory { addr: ffd8, size: 01 }
Recv: MemoryData(MemoryView { base: ffd8, data: [01] })
Sent: ReadMemory { addr: fffe, size: 02 }
Recv: MemoryData(MemoryView { base: fffe, data: [06, cb] })
Sent: Unknown { cmd_id: 40, payload: [] }
Recv: Unknown { cmd_id: 40, payload: [40, 15, 24] }
Sent: ReadMemory { addr: ffe5, size: 01 }
Recv: MemoryData(MemoryView { base: ffe5, data: [00] })
Sent: ReadMemory { addr: ffe0, size: 01 }
Recv: MemoryData(MemoryView { base: ffe0, data: [00] })
Sent: ReadMemory { addr: ffda, size: 02 }
Recv: MemoryData(MemoryView { base: ffda, data: [41, 00] })
Sent: Unknown { cmd_id: 45, payload: [a1, 03, 00, 00, 02] }
Recv: Unknown { cmd_id: 45, payload: [45, a1, 03, 00, 03, ff, b8, 00, 00, 00, 00] }
Sent: SetMute { value: true }
Recv: Ack
Sent: WriteMemory { addr: ffcc, data: [02, ac, db, 37] }
Recv: Ack
Sent: SetMute { value: false }
Recv: Ack

Input levels are all zeros:

$ minidsp
MasterStatus { preset: 1, source: Toslink, volume: Gain(-32.5), mute: false, dirac: true }
Input levels: 0.0, 0.0
Output levels: 0.0, 0.0, 0.0, 0.0

delay hard limit

Currently the delay is hard limited to 8000 samples in lib.rs (line 422). Which is in my case of a ddrc88 around 160ms. However my device can delay up to 1 full second and in some cases I need that to be availlable. For now I adjusted the this number to 48000 and recompiled, which works. Maybe it warrents something to be able to have it configured correctly per device?

2x8 (4x10HD) and OpenDRC DA-8 (miniSHARC) support

There should be enough info provided in mrene/node-minidsp#9 to support the 4x10HD.

Information to gather:

• XML Config files
• USB vendor / product ids
• Hardware ID returned by that command

TODO:

• Split device probing into its own component
• Adjust lib example to use device discovery
• Add config generator
• Testing with someone who has that device

Support for minidsp DDRC-24 with Dirac Live

Hi,

It would be great to provide support for minidsp DDRC-24 with DiracLive to control this function (DL on/off).

Here's the output of minidsp debug id:

Probing local hid devices: 
Found: [2752:0044] path=0001:0004:04

HW ID: 10
DSP Version: 101
Detected sources: [(Analog, 0), (Toslink, 1), (Usb, 2)]

Dumping memory:
len=95
0000FFA0  FF 65 FF 03 20 03 2C 01 03 00 64 00 00 00 00 00  | .e.♥ ♥,☺♥.d..... |
0000FFB0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ |
0000FFC0  00 00 FF FF F8 FF FF FF 05 DC A6 77 04 F0 D4 B6  | ....▫...♣▄ªw♦≡╘╢ |
0000FFD0  01 81 5F 42 02 10 3A 3B 01 01 4E 01 FF FF FF FF  | ☺ü_B☻►:;☺☺N☺.... |
0000FFE0  00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF  | ................ |
0000FFF0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF 06     | ..............♠  |

Maybe this link could be also useful (info about command/response for minidsp settings)
Volume display - minidsp forum

miniDSP Flex Support

Is it possible to get miniDSP Flex support working?

I'm moberhardt on AVSForum and runs one of the filter repositories.

The flex uses the same plugin as 2x4HD, same specs channel and filter wise, and loads the XML files fine

Running basic command line sort of works, but doesn't show source/input:
MasterStatus { preset: 1, source: NotInstalled, volume: Gain(-0.0), mute: false, dirac: false }
Input levels:
Output levels:

Loading a filter via ezbeq doesn't work though

`During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "ezbeq\apis\ws.py", line 111, in __send_to_all
File "autobahn\websocket\protocol.py", line 2254, in sendMessage
autobahn.exception.Disconnected: Attempt to send on a closed protocol
2022-05-09 16:39:04,984 - PoolThread-twisted.internet.reactor-3 - ezbeq.ws - INFO - unregister - Unregistering client tcp4:192.168.0.16:50614
2022-05-09 16:39:04,984 - PoolThread-twisted.internet.reactor-3 - ezbeq - ERROR - log_exception - Exception on /api/2/devices/master [PATCH]
Traceback (most recent call last):
File "flask\app.py", line 1516, in full_dispatch_request
File "flask\app.py", line 1502, in dispatch_request
File "flask_restx\api.py", line 403, in wrapper
File "flask\views.py", line 84, in view
File "flask_restx\resource.py", line 49, in dispatch_request
File "ezbeq\apis\devices.py", line 303, in patch
File "ezbeq\device.py", line 161, in update
File "ezbeq\minidsp.py", line 597, in update
File "ezbeq\device.py", line 254, in _hydrate_cache_broadcast
File "ezbeq\minidsp.py", line 585, in __do_it
File "ezbeq\minidsp.py", line 624, in __update_slot
File "ezbeq\minidsp.py", line 538, in set_gain
File "ezbeq\device.py", line 254, in _hydrate_cache_broadcast
File "ezbeq\minidsp.py", line 535, in __do_it
File "ezbeq\minidsp.py", line 439, in __send_cmds
File "concurrent\futures_base.py", line 444, in result
File "concurrent\futures_base.py", line 389, in __get_result
File "concurrent\futures\thread.py", line 57, in run
File "ezbeq\minidsp.py", line 562, in __do_run
File "plumbum\commands\base.py", line 240, in run
File "plumbum\commands\base.py", line 201, in runner
File "plumbum\commands\processes.py", line 322, in run_proc
File "plumbum\commands\processes.py", line 24, in _check_process
File "plumbum\machines\base.py", line 28, in verify
plumbum.commands.processes.ProcessExecutionError: Unexpected exit code: 1
Command line: | minidsp.exe -f 'C:\Users\oberh\AppData\Local\Temp\tmpsapvg49q'
Stderr: | Error: Specified channel or peq is out of range`

If there is anything I can do to help diagnose it or assist let me know.

Index.html cannot connect to official app

Unfortunately I have hit a wall with this installation. I’m trying to use the official minidsp app to control my SHD.

I have installed the latest .deb on my Ubuntu VM using apt-get install ./minidsp....deb and passed through the USB connection to my SHD, and I have enabled the service using

systemctl enable minidsp.service
systemctl start minidsp.service

Minidsp probe shows the SHD, and it appears in the Minidsp app as well. However, as soon as I try and connect, I receive an error message saying index.html connection closed.

I am not running the device console.

My config.toml file located in etc/minidsp is

[[http_server]
# bind_address = "127.0.0.1:5380"
# Replace the previous line by this one in order to allow connections from other hosts
bind_address = "0.0.0.0:5380"

# TCP servers can be setup to support using the native "plugin" apps to manage the device
[[tcp_server]]
# bind_address = "127.0.0.1:5333"
# Replace the previous line by this one in order to use the plugin app from another machine
bind_address = "0.0.0.0:5333"

# Advertise the following address for the official minidsp mobile app
advertise = { ip = "192.168.2.12", name="MiniDSP SHD" } 

Since I want to control the SHD from my phone, I uncommented the line suggested to use from another machine.

I have tried several different combinations with the same message appearing no matter.

systemctl status minidsp.service is showing

minidsp.service - MiniDSP Server
     Loaded: loaded (/lib/systemd/system/minidsp.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2023-01-16 16:20:06 UTC; 2s ago
   Main PID: 2445 (minidspd)
      Tasks: 6 (limit: 2237)
     Memory: 1.8M
        CPU: 8ms
     CGroup: /system.slice/minidsp.service
             └─2445 /usr/bin/minidspd --config /etc/minidsp/config.toml

There are no firewall rules or VLAN’s interfering on my network as far as I know, I have a very simple environment.

Has anyone encountered this issue or able to provide any clues as to where I should look to debug this issue ?

.deb installs executable in /usr/bin, but minidsp.service expects it in /usr/local/bin

The .deb installs the minidsp executable in /usr/bin, but the minidsp.service references /usr/local/bin.

$ which minidsp
/usr/bin/minidsp

Jan 12 19:37:38 server systemd[1009]: minidsp.service: Failed to execute command: No such file or directory
Jan 12 19:37:38 server systemd[1009]: minidsp.service: Failed at step EXEC spawning /usr/local/bin/minidsp: No such file or directory
Jan 12 19:37:38 server systemd[1]: minidsp.service: Main process exited, code=exited, status=203/EXEC
Jan 12 19:37:38 server systemd[1]: minidsp.service: Failed with result 'exit-code'.
Jan 12 19:37:39 server systemd[1]: minidsp.service: Scheduled restart job, restart counter is at 5.

Service starts fine once I moved the file to /usr/local/bin.

Failure: Transport has closed

I'm running the minidsp-rs server and I received the following error after starting the service. Is this something I need to address, if so how?

Feb 02 05:22:20 raspberrypi systemd[1]: Started minidsp. Feb 02 06:00:04 raspberrypi minidsp[978]: [2021-02-02T11:00:04Z ERROR minidsp::server] stream rx: Err(Lagged(1)) Feb 02 06:00:04 raspberrypi minidsp[978]: Error: Transport has closed Feb 02 06:00:04 raspberrypi systemd[1]: minidsp.service: Main process exited, code=exited, status=1/FAILURE Feb 02 06:00:04 raspberrypi systemd[1]: minidsp.service: Failed with result 'exit-code'.

PWR-ICE125 / PWR-ICE250 device support?

Do you expect the PWR-ICE plate amplifiers to be supported?

https://www.minidsp.com/products/plate-amplifiers/pwr-ice125
https://www.minidsp.com/products/plate-amplifiers/pwr-ice250

They have a LAN control interface, no USB.
The datasheet states ADAU1445 SigmaDSP is used internally.

Cleanup readme using collapsable sections

Example:

Click to expand!

Heading

1. A numbered
2. list
   • With some
   • Sub bullets

device status is unclear in 0.1

I copied this over from the 0.1 thread. I'm not sure what the root cause is but it looks like the http or ws api can be pushed into a fundamentally broken state

At some point, I hit /devices and get

  {
    "url": "usb:0001%3A003f%3A04?vid=2752&pid=0011",
    "version": null,
    "product_name": null
  }
]

it's not obvious whether this is a good or bad thing

/devices/0 says

{
  "message": "the specified device is not ready to accept requests",
  "error": {
    "type": "DeviceNotReady"
  }
}

this also returns a 500 status code

if I hit the websocket then this also returns a 500 which is (I think) an unusual response for a websocket however if I use the cli then I do get a normal response showing the device status

$ minidsp
MasterStatus { preset: 1, source: Usb, volume: Gain(-2.0), mute: false, dirac: false }
Input levels: -131.4, -131.4
Output levels: -125.3, -125.3, -120.0, -125.3

i.e. an apparently functioning system

after a

sudo systemctl restart minidsp

then I get normal responses and the ws is happy again

[2021-08-16T18:50:05Z ERROR minidsp::transport::multiplexer] recv loop exit: ParseError(EmptyPacket)

C:\Calibration Automation\minidsp.x86_64-pc-windows-msvc>minidsp.exe probe
[2021-08-16T18:50:05Z ERROR minidsp::transport::multiplexer] recv loop exit: ParseError(EmptyPacket)
Found 2x4HD with serial 90#### at usb:%5C%5C%3F%5Chid%23vid_2752%26pid_0011%26rev_06f2%26mi_04%238%2622799767%260%260000%23%7B4d1e55b2-f16f-11cf-88cb-001111000030%7D?vid=2752&pid=0011 [hw_id: 10, dsp_version: 100]
Found 2x4HD with serial 90#### at usb:%5C%5C%3F%5Chid%23vid_2752%26pid_0011%26rev_06f2%26mi_04%238%26770d6d3%260%260000%23%7B4d1e55b2-f16f-11cf-88cb-001111000030%7D?vid=2752&pid=0011 [hw_id: 10, dsp_version: 100]

C:\Calibration Automation\minidsp.x86_64-pc-windows-msvc>

Not sure why I am getting the error.

version 0.1.2
I did have to write the actually serial numbers (redacted above) to the unit, as the standard 965535 serial was assigned to both of them. I assigned the actual serial number to both of them by disabling each unit with a USB tool in windows.

Nano Digi USB support

Discussed in #149

^{Originally posted by Martin-By June 13, 2021}
Hi,
I am not profession in linux coding, but could install the executable files within /usr/local/bin.
Running "minidsp" it returns: "Error: No devices found"

The Device is found by system:
lsusb: Bus 003 Device 002: ID 04d8:003f Microchip Technology, Inc. nanoDIGI v2.6

and mapped as hidraw0:
crw-rw-rw- 1 root root 242, 0 Jun 13 11:09 /dev/hidraw0

within "/etc/udev/rules.d" I created a file "50-minidsp_usb.rules"
SUBSYSTEM=="usb", ATTR{idVendor}=="04d8", ATTR{idProduct}=="003f", MODE="0666"

ubuntu@musicserver1:~$ cat /sys/class/hidraw/hidraw0/device/uevent
DRIVER=hid-generic
HID_ID=0003:000004D8:0000003F
HID_NAME=miniDSP LTD. nanoDIGI v2.6
HID_PHYS=usb-0000:00:1d.1-1/input0
HID_UNIQ=
MODALIAS=hid:b0003g0001v000004D8p0000003F

root@musicserver1:/dev/input# minidsp probe
thread 'main' panicked at 'index out of bounds: the len is 2 but the index is 2', protocol/src/commands.rs:575:53
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

What I am doing wrong with my setup to use minidsp?

My Device: MiniDSP_2x8_nanoDIGI_204
Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-74-generic x86_64)

Devices not cleaned up on disconnect if a ws is active

Using 0.1.0, it looks like the websocket interface does not handle device connection issues properly

• start minidsp service
• connect a minidsp
• listen on ws://localhost/devices/0?levels=true
• see levels coming through
• pull the USB cable
• get a disconnect event
• reconnect the USB cable
• no reconnect event on the ws (using a client which does reconnect)
• check the devices via the rest api and find the previous device 0 is still present

$ curl -i  --unix-socket /tmp/minidsp.sock http://localhost/devices                                                                                                                   

HTTP/1.1 200 OK
content-type: application/json
x-powered-by: Routerify v2.1.0
content-length: 292
date: Sun, 06 Jun 2021 19:05:22 GMT

[
  {
    "url": "usb:0001%3A004d%3A04?vid=2752&pid=0011",
    "version": null,
    "product_name": null
  },
  {
    "url": "usb:0001%3A004e%3A04?vid=2752&pid=0011",
    "version": {
      "hw_id": 10,
      "dsp_version": 100,
      "serial": 965535
    },
    "product_name": "2x4HD"
  }

• terminate the process with the ws client
• bad device will remain in the devices list until the minidsp service is restarted

Add commands to increment/decrement volume

Any chance you could add an option to run as minidsp.exe -vol-up ?
That way, i could link it to a keyboard shortcut or a dial of some kind to step the volume up and down (either by the default amount, or by a set db step). Having to set the specific volume level makes it not easy to work with incrementally.

Originally posted by @ryan00davis in #225

Read commands from a text file to apply partial configuration settings

MiniDSP Flex Input Switching Delay

Just a minor issue with ending command sequences to the flex that start with an input switch, the Flex is somewhat slower than the 2x2HD and takes approximately 4-5 seconds. So if you are say using ezBEQ and selecting a slot to load a filter into, it doesn't load. @3ll3d00d at avsforum who does ezbeq (https://github.com/3ll3d00d/ezbeq) said it would!d need to be changed on the minidsp rs side.

Thanks

Connection to minidsp 2x4HD breaks after using IR remote

Hi!

I installed minidsp-rs on my old C.H.I.P. computer which which is a kind of raspberry pi that runs debian buster now and everything works good, I can connect to my 2x4HD using the original GUI and do all the changes, for example update and change profiles. BUT, if I start changing profiles with the IR Remote control while connected to the GUI using minidsp-rs, I see the change of a Config profile but then I get a dialog that the connection was broken. In the logs I see this:

Dec 20 18:28:13 chip systemd[1]: Started MiniDSP Server.
Dec 20 18:28:13 chip minidspd[1285]: App is listening on: /tmp/minidsp.sock
Dec 20 18:28:14 chip minidspd[1285]: App is running on: 0.0.0.0:5380
Dec 20 18:28:44 chip minidspd[1285]: [2021-12-20T17:28:44Z ERROR minidsp::transport::hub] device_tx: An HID error has occurred: hidapi error: hid_error

Receiving frequent errors after upgrading to 0.1.1

Getting this error several times a night, which is only resolved with a hardware reset of the Mini DSP 2x4HD: error; EzBeq.getdevices failed, HTTP status 500. Log entry indicates the following: ProcessTimedOut: ('Process did not terminate within 10 seconds', ['/usr/bin/minidsp', '--tcp', '127.0.0.1']).

Is it possible to automatically overflow crossover PEQ?

I'm looking to use the MSO strategy of loading input PEQs into the output channel PEQ and output channel specific PEQ into the crossover slots.

The files exported don't account for the two groups of four crossovers. Is there a way to enable automatic overflow of the first crossover group into the second? The error printed is:

Warning: Some filters were not imported because they didn't fit (try usingall)

so some user convenience and potentially dropping the need to specify groups would be great.

I'm really hoping to load a set of 8 PEQ into the crossover slots all at once. This is possible with copy paste through the GUI, so I'm hoping we can make it work here.

Release for arm64 architecture ?

Hello and thank you for the great work !

I have been trying to install your program on a rock64 device with Ayufan linux build but the architecture is declared as arm64 instead of armhf so it fails with following error message:

>dpkg -i minidsp_0.1.2_armhf.deb
dpkg: error processing archive minidsp_0.1.2_armhf.deb (--install):
 package architecture (armhf) does not match system (arm64)

I tried to install cargo and compile the project but I get various build errors for external libraries (riff, urlencoding, bimap, ...).
I never used rust so I cannot debug it properly to get the build done.

Would it be possible to provide an arm64 release too ?
If not, can you provide some instructions on how to build the project ?

Thank you !

Wi-DG not detected by `minidsp probe`

interpretation delay parameter

I have been using the tool after we added the DDRC88BM support in the dev build. One application for me is setting the delay for all channels (to do AV sync here). It seemed to not do much, so I looked at what happened: The communication of the plugin seems to specify the delay as an int for the amount of samples to delay, i.e. 1 second delay is being sent as the int 48000 (and it runs a 48kHz processing\sampling).

Currently the source code interpreted 1 as 0.1 millisecond and directly sends integers based on that, however I think that is coincedently almost corr3ect for a device with a sample rate of 96000 sampling, e.g. the HD devices.

A second issue is that the delay is hard limited to the value 80, but my device can go up to 48000. I here adjusted this level in minidsp\src\lib.rs, but maybe this should be a device dependent limit.

It is a bit over my head to suggest code differences this time for both issues :-).

version `GLIBC_2.29' not found

I've just installed minidsp-rs on Debian 10. Hardware is an Intel nuc
I've used the "minidsp_0.1.7_amd64.deb" release
hostnamectl Static hostname: server-familie Icon name: computer-desktop Chassis: desktop Machine ID: 329b9eaea9c64edc9f55ab952f36762c Boot ID: a2819175ee72444f987a4645ce7fdac7 Operating System: Debian GNU/Linux 10 (buster) Kernel: Linux 4.19.0-17-amd64 Architecture: x86-64
The minidsp server doesn't start
This is my syslog output
Jul 29 12:23:14 server-familie systemd[1]: Started MiniDSP Server. Jul 29 12:23:14 server-familie minidspd[23686]: /usr/bin/minidspd: /lib/x86_64-linux-gnu/libm.so.6: versionGLIBC_2.29' not found (required by /usr/bin/minidspd)
Jul 29 12:23:14 server-familie systemd[1]: minidsp.service: Main process exited, code=exited, status=1/FAILURE
Jul 29 12:23:14 server-familie systemd[1]: minidsp.service: Failed with result 'exit-code'.
Jul 29 12:23:14 server-familie systemd[1]: minidsp.service: Service RestartSec=100ms expired, scheduling restart.
Jul 29 12:23:14 server-familie systemd[1]: minidsp.service: Scheduled restart job, restart counter is at 5.
Jul 29 12:23:14 server-familie systemd[1]: Stopped MiniDSP Server.
`
Is it possible that mindsp-rs doesn't work on debian10?

Config change hangs client

Hi,

Another issue :)

It looks like the minidsp is sending back an ambiguous response when attempting to change the config.
When I execute minidsp --tcp 192.168.86.40:5333 config 0 from my windows 10 PC to my pi, both running 0.0.3 I get the following in my Pi log:

New connection: 192.168.86.54:65079
Sent: SetConfig { config: 00, reset: true } 
Recv: MaybeConfigChanged

And the command on the PC hangs. This happens whether I set the config to the same as current, or a different config.

It also works with a local, directly connected set-up.

Let me know if you need more info

Thanks

Debian package should include udev rules

The docs indicate how to setup udev rules so privileged access isn't required to open the usb device, this should be done automatically when installing from a package.

Couple of naive questions (to be added in documentation ?)

Hello and thank you for this tool.

I have a couple of very naive questions regarding this tool.
Maybe this could be clarified in the early pages of documentation. My apologies if it is already there but I did not find it.

Question 1:
I have a minidsp SHD and I initially assumed your tool uses the provided websocket interface to control it but I doubt it now.
Does your tool work only on usb-connected devices or can it connect to remote devices through network ?

Question 2:
How does your tool work (communication with device), and how did you manage to get initial documentation to create it (device connection protocol, commands) ?
Did you have to reverse-engineer communication protocol between devices and configuration application ?

Question 3:
Are you affiliated with minidsp ? Is your tool going to be promoted/supported by them at some point ?

Thank you for your answers !

When I run the .exe, the .exe immediately closes.

I don't know if I'm opening it correctly. Does it work if the MiniDSP application is also running, and does it matter whether or not that application is connected to my MiniDSP? I've got minidsp-rs listed in the settings for BEQ Designer, and maybe BEQ Designer is using it, and that's why minidsp-rs won't stay open. However, I've already tried running minidsp-rc without BEQ Designer running, and minidsp-rc won't stay open.
I got it by downloading "minidsp.x86_64-pc-windows-msvc.zip" earlier this week.
My MiniDSP is a DDRC-24 running firmware version 1.14. It's connected via USB to my Windows 10 PC. Its Windows application version is 1.11. Windows 10 is up to date.

feature request: list of known working devices please?

Hi,

Can you add a list of MiniDSP devices this is known to work with in the README?
Does it work with the old "classic" miniDSP 2x4?

kind regards.

Support for asynchronous reading of minidsp status + DDRC-24 support

Hi,

As we discussed HERE in "Discussions" section it would be a good idea to implement asynchronous device events (to get updates on the same way as native desktop app does). It could be used i.e. to get regular updates on OLED display, instead of sending continuously commands to get the status of the device (needs a lot of cpu power).