TOPIC:

Hi!

Thanks for making the IL-DSP, I just received mine and I'm really happy:
I've been hoping for this kind of hardware for many years, mostly to compensate for the lack of system-wide EQ on mobile operating systems.

However I'm immediately facing an obvious limitation: a complete lack of mobile devices support on the software side.

Use case: I'll use the USB DAC+DSP mostly on my phone with 3 types of headphones, each needing a different correction.
On desktop? The IL-DSP is not that useful: software correction do the job just fine (eqMac2 on MacOS, my own software on Linux).

Furthermore, I have in the works for some time a mobile app that allows to interactively generate correction parametric EQ biquads, and I was hoping to send use the IL-DSP as target hardware.

Now, there are two main ways to make this possible:

1. miniDSP opening and documenting the USB protocol used to send and apply filters to the IL-DSP
2. miniDSP writing a closed, basic Android app sends filter configuration to the IL-DSP over USB, and accepts filter input from external app. Like an automated "import from biquads.txt" functionality

Each approach has pros and cons.

As senior software engineer by trade with years of experience of Android development, who worked with an audio company for some time: I'd be happy to help you in this journey.
What do you think?

No answer from @devteam
Are you (quietly) suggesting reverse-engineering of the IL-DSP USB protocol?

@Supercurio

While we never advertize our future roadmap (company policy if you know a bit of our history, we stick to it), we indeed already have some android app able to control our DSP. It's under the HA-DSP. For us to do the same, it would require to slightly modify that app to be compatible with the IL-DSP.. Eventually, we may do it... We don't have plans at this time to build your requirements this being said (i.e. custom API). That's a different ball game and suddenly turn our engineers to start debugging 3rd party issue as it's been the case every single time we've opened API (to customers or our B2B biz)... Not 100% sure our management team will like that idea so can't comment on this idea I'm afraid...

Devteam

Thanks @devteam

It would certainly be a good idea to add support to the IL-DSP in the app currently supporting HA-DSP, especially since IL-DSP doesn't support presets.
By the way, the Android app is in the range of 10+ installs
play.google.com/store/apps/details?id=com.minidsp.hadsp&hl=en
Experience shows that companion mobile apps for hardware should be free of charge, the purchase of the hardware should cover the development costs for both hardware and software.
The current pricing model ends up only limiting the product's capabilities, especially as many households will use both iOS and Android devices, therefore ending up buying the same thing several times.

An API for third-party apps to set EQ filters via your app would be trivial to implement in a safe and secure way, and my offer stands on helping you to build that if you're interested.

In the meantime, I'll try to find the available time to make a reverse-engineered mobile app for the IL-DSP then.

devteam wrote:

@Supercurio

While we never advertize our future roadmap (company policy if you know a bit of our history, we stick to it), we indeed already have some android app able to control our DSP. It's under the HA-DSP. For us to do the same, it would require to slightly modify that app to be compatible with the IL-DSP.. Eventually, we may do it... We don't have plans at this time to build your requirements this being said (i.e. custom API). That's a different ball game and suddenly turn our engineers to start debugging 3rd party issue as it's been the case every single time we've opened API (to customers or our B2B biz)... Not 100% sure our management team will like that idea so can't comment on this idea I'm afraid...

Devteam

@devteam

Can you confirm that you're definitely working on making the HA-DSP Android app compatible with the IL-DSP (and free of charge)? As the IL-DSP is a small, light, primarily portable device designed for mobile use (and marketed as such), a free app to control the DSP is essential for its majority use case. Having to connect the device to a PC every time you want to change the EQ profile is very cumbersome, and makes this impossible while travelling for example. I, and I trust many other users, would very much appreciate this functionality, and it would add an extra incentive for prospective buyers that you could include in your marketing.

Progress update:

I've started reverse-engineering the IL-DSP USB protocol yesterday night.
I believe I already understand most of the commands that will be useful to make an Android app capable of:

• toggle DSP bypass on/off
• link/unlink channels
• set filters for left channel, right channel or both
• generate filters from a GUI, or load form an existing XML preset file

I've not started prototyping a proof of concept yet, so this list might be off to some extent.

@devteam thanks for making the protocol not too complex I guess

Progress update: first proof of concept success

I started with the easiest one (not requiring reading back from the USB endpoint): enabling/disabling DSP bypass by code.
Works a treat!

I'm now confident it'll be possible to make an Android app for the IL-DSP without @devteam's help.
It would be nice to have a Linux one as well.... or going further, maybe getting rid of the horrible Adobe AIR app altogether.

Progress update: now got a working minimal Android App proof of concept

Promising !

Progress update: now reverse-engineered most of the configuration protocol

Decoding:

• Config timestamp
• Current DSP Bypass status
• DSP Bypass status change
• Serial Number
• Firmware version
• Hardware ID

Implemented:

• Set DSP Bypass status
• Set single EQ band biquads (transition/final, left/right/linked)
• Synchronize full config
• Set config timestamp

I publish this list here so @devteam can see now that it's for real and happening; a few things can't just only be guesses without exhaustive reverse-engineering.
Time to embrace with some support and collaboration, if only to ensure your customers will have a flawless experience.
The reasoning is that soon, a significant part of the usage might be through my incoming app and programs instead of miniDSP's own offering.


There are a few commands and responses I don't understand yet. They are likely not required for a complete re-implementation.
Additionally, I've been exploring options to guarantee clipping prevention. Promising but have not tested and measured yet.

It bodes well for incoming or future implementations of:

• Android App
• Command line utilities (load REW EQ configs directly, Linux support)
• Alternative computer GUI, including with Linux support
• Raspberry Pi / Arduino / anything support

What I suppose won't happen is a pure iOS app version since @devteam says that the product is not MFi compliant: therefore there is no way to carry over the custom USB protocol to the IL-DSP, only standard USB-Audio will work.
Someone could make custom hardware you insert in-between the iOS device and IL-DSP tho, acting as MFi bridge.
Frankly, miniDSP products should already be MFi compliant IMHO. From experience in the industry working with headphones, the extra hardware cost is absolutely sustainable for a $99 product.

Android App and command line utilities (including Linux): I'll build myself.
Other multiplatform GUI (QT, Web, Electron): likely not.
Other platforms: cool things might happen, although there might not be that many use cases for the IL-DSP itself in that case since the only connect is USB, shared between audio and configuration. But for other miniDSP products certainly, if they also get reverse-engineered. Protocols might have a lot in common.

Do you know if it's the same protocol as the 2x4HD and other devices? I'm working on an (open source) command line client for managing its settings in a standalone way: github.com/mrene/minidsp-rs

(If you don't have one, do these look familiar? github.com/mrene/minidsp-rs/blob/29a8ab3...src/commands.rs#L106)

I've got most of the config import figured out, but I can't seem to wrap my head around the last 0x06 block (and what 0x07 means, I have speculations but that's all). Feel free to DM me on twitter (@mathieurene) if you want to chat about it - I'd love to hear if it works with that device too and what it'd take to adapt my CLI to it.