Open professorpolymath opened 6 years ago
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
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
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)
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
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...
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.
Here are default config files from two platforms, the miniDSP 2x8 (4x10), and miniSHARC 4x8: minidsp_cfg_xml.zip
Thanks! Would you be able to get the USB product id as well? lsusb should tell you.
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
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.
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
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!