Skip to content
This repository has been archived by the owner on Dec 14, 2021. It is now read-only.

almost works with miniDSP 4x10 HD... #9

Open
professorpolymath opened this issue Oct 4, 2018 · 11 comments
Open

almost works with miniDSP 4x10 HD... #9

professorpolymath opened this issue Oct 4, 2018 · 11 comments
Assignees

Comments

@professorpolymath
Copy link

Hello. I've been experimenting with this tool and my miniDSP 4x10 HD (running firmware 2.11). Most of the functions work without modification -- digital source selection, preset selection, and setting the volume level. However reading the current volume level doesn't work. I would like to fix this. Can you give me an idea of what debug info is needed to make the needed changes?
thanks!

@mrene
Copy link
Owner

mrene commented Oct 6, 2018

Great to see it being tested with other products :)

Have you tried increasing the number of channels to 4 here to see if it would report input levels on all channels?

Are you seeing values being reported when running minidsp monitor at all?

If you do, I would inspect what type of replies the device sends while being queried for the volume information, the easiest way to see the data being exchanged is to set the DEBUG environment variable to minidsp:transport:usb

If you don't, then you'll have to look at what the official air app does and analyze it, the easiest way is to sniff the traffic between the app and its proxy component (the air app ships with a proxy so they can send HID messages from the runtime, it listens on localhost:5333. When you are on a screen which displays the input levels, you should see rapid requests/responses (1 per channel) - based on that you should be able to change the command to read the data correctly. It helps to have a fixed input level and record the dB value so it can be verified.

To analyze them just grab the data part of the packets - I use tshark -r $file -T fields -e data > $file.txt

@mrene mrene self-assigned this Oct 6, 2018
@professorpolymath
Copy link
Author

Thanks for the pointers, much appreciated!
minidsp monitor fails with:

(node:16739) UnhandledPromiseRejectionWarning: Error: Unexpected response
                                                                          pD�
    at sendCommand.then (/usr/local/lib/node_modules/minidsp/src/device.js:150:11)
(node:16739) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)

Adding two channels to const inputChannels doesn't change the error.

A packet dump taken while clicking in turn on the VU meter for each of the four input channels produces the following values. I interpret these to mean that the channel is indicated by 062903820e...., followed by floating signal levels, every 200 ms or so. Is that correct?

ch1/analog left (near-silence)
062903820e 0a cc
0802039200 00 01 c2
0802039200 00 01 ec
0802039200 00 01 17
ch2/analog right (near-silence)
062903820e 0b cd
0802039200 00 01 5c
0802039200 00 01 1f
0802039200 00 01 57
ch3/digital left (sine signal)
062903820e 0c ce
0802039200 6c 78 5e
0802039200 6c 78 42
0802039200 6c 78 5c
0802039200 6c 78 51
ch4/digital right (sine signal)
062903820e 0d cf
0802039200 6c 78 5f
0802039200 6c 78 30
0802039200 6c 78 60
0802039200 6c 78 48

@professorpolymath
Copy link
Author

Incidentally, here's what I learned using the fuzz script by @markubiak to read the miniDSP 4x10 state, which differs slightly from the 2x4 in that there are three digital inputs (analog vs digital input is controlled by the selected preset).

miniDSP 4x10 HD
register 14 05 ff dX:
ffd8 = 00, 01, 02, 03  (preset 1, 2, 3, 4)
ffd9 = 00, 01, 02  (input: SPDIF, TOSLINK, AES/EBU)
ffda = 00 to ff  (IR master volume: 256 hex steps from 0dB to -127.5dB)
ffdb = 00, 01  (not-mute, mute)

@mrene
Copy link
Owner

mrene commented Dec 31, 2020

Hey there after 2 years, I'm working on a rust rewrite which would support multiple devices. Any chance you could help filling in values for the 4x10HD? There's a pretty simple flow for sniffing out the addresses from the official app by proxying them. The data structure would look like this https://github.com/mrene/minidsp-rs/blob/master/src/device.rs

@professorpolymath
Copy link
Author

Bonjour Mathieu. I will try to help. I will need some time to look at this again; after two years it has completely left my brain...

@mrene
Copy link
Owner

mrene commented Jan 21, 2021

Bonjour :) I've learned quite a bit more about the protocol since that message, most of the commands are referring to addresses within the xml config filie generated by the app. Could you send me one for the 4x10? Most components follow a semi-obvious pattern after that (although sometimes, there are extra things in the config that aren't on the device, and the offsets start at weird places, but most of it is there)

Once I can add this to the app, it will print out decoded messages with resolved addresses making the process a lot more trivial.

@professorpolymath
Copy link
Author

Here are default config files from two platforms, the miniDSP 2x8 (4x10), and miniSHARC 4x8:
minidsp_cfg_xml.zip

@mrene
Copy link
Owner

mrene commented Jan 22, 2021

Thanks! Would you be able to get the USB product id as well? lsusb should tell you.

@professorpolymath
Copy link
Author

Both devices report the same Product ID: ID 04d8:003f Microchip Technology, Inc.
Attachment contains lsusb -v for 4x10 HD (miniDSP 2x8) and the OpenDRC DA-8 (miniSHARC). The only difference between them is the name under iProduct.
minidsp_lsusb.zip

@mrene
Copy link
Owner

mrene commented Feb 7, 2021

Uhm this makes distinguishing them a bit harder. Any chance you could run minidsp-rs and paste the output of minidsp --usb 04d8:003f debug id ?

It'll dump something like this:

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

Dumping memory:
len=95
0000FFA0  FF 64 FF 03 20 03 2C 01 03 00 64 00 FF FF FF FF  | .d.♥ ♥,☺♥.d..... |
0000FFB0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  | ................ |
0000FFC0  FF FF FF FF F8 FF FF FF 01 A3 87 E7 02 B6 E3 24  | ....▫...☺úçτ☻╢∏$ |
0000FFD0  00 5B B9 5A 00 E6 A3 6D 00 01 2E 00 FF FF FF FF  | .[╣Z.µúm.☺...... |
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 FF     | ...............  |

Dumping readable floats:
0044: -131.44876
0045: -131.44876
004a: -155.50768
004b: -155.22597
004c: -120.0
004d: -120.0

Hopefully they'll have different hardware ids - the sources detector runs the same logic as their phonegap app, which had that logic embedded in javascript.

@professorpolymath
Copy link
Author

The command reports HW ID: 1 on the minDSP 4x8, and then hangs at Dumping readable floats.
The miniSHARC reports HW ID: 4. Full output of each in attached file.
minidsp_HW_IDs.zip

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants