Hardware

The amplifier has 4 XLR inputs and 4 speakon outputs.

The analog volume controls are linear and noisy.

The built-in fan is unbearably loud, but can be replaced by other (potentially temperature-controlled) fans.

DSP

This amp has a DSP which can be controlled/programmed through a Windows-only software (bottom of page).

The DSP connects as a USB HID device with vendor id 0x0168 and product id 0x0821.

dmesg output under linux on connecting:

[784190.917824] usb 3-7: new full-speed USB device number 5 using xhci_hcd
[784191.066924] usb 3-7: New USB device found, idVendor=0168, idProduct=0821, bcdDevice= 0.00
[784191.066934] usb 3-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[784191.066938] usb 3-7: Product: Dsp Process
[784191.066941] usb 3-7: Manufacturer: Musicrown
[784191.068640] input: Musicrown Dsp Process as /devices/pci0000:00/0000:00:14.0/usb3/3-7/3-7:1.0/0003:0168:0821.0003/input/input19
[784191.068841] hid-generic 0003:0168:0821.0003: input,hidraw2: USB HID v1.10 Device [Musicrown Dsp Process] on usb-0000:00:14.0-7/input0

The software runs on wine, but we have not succeeded in connecting to the device using a docker/wine combination.

The command used is: docker run -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix --rm -it -v ~/dev/aesrl/docker-wine:/home/wineuser/dsp -v "$HOME/.Xauthority:/root/.Xauthority:rw" --net=host --device=/dev/hidraw2 scottyhardy/docker-wine bash

After launching the docker, the DSP programming software can be installed under wine. However, the software cannot find the USB device.

USB HID protocol

Under Windows, it is possible to sniff on the USB traffic using usbpcap

The HID data is 64 bytes in length, total packet length 91 bytes:

0000   1b 00 b0 e4 5c b6 0d a1 ff ff 00 00 00 00 09 00
0010   01 01 00 07 00 81 01 40 00 00 00 10 02 01 00 10
0020   13 34 78 34 4d 49 4e 49 50 52 4f 20 56 30 31 30
0030   10 03 72 1c 00 d7 1b 00 9c 00 00 00 10 03 67 00
0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050   00 00 00 00 10 03 09 00 30 71 77

The actual data begins at byte 0x1b with a header 10 02 01 00.

The next byte (in this case 0x10) is the net data length (16 bytes).

The next byte (in this case 0x13) is the data type, in this case the product string with a length of 15 bytes.

The next two bytes are always 0x10 0x03, the following one (0x72) presumably a checksum.

The following data types have been seen so far:

  • 0x01: presence? (length 0x01)
  • 0x10: ? (length 0x02)
  • 0x12:
  • 0x13: product string (length 0x10): "4x4MINI PRO V010"
  • 0x14: ? (length 0x02)
  • 0x20:
  • 0x22: ? (length 0x1f)
  • 0x24: preset data?: id (1 byte, 0x00-0x08), data bytes (total length 0x34)
  • 0x27:
  • 0x29: preset name: id (1 byte, 0x00-0x1d), name string (14 bytes), (total length 0x10)
  • 0x2c: ? (length 0x08)
  • 0x31: lp flt adjust/slope/bypass: id (1 byte, 0x04-0x07…output), 3 data bytes (total length 0x05)
  • 0x32: hp flt adjust/slope/bypass: id (1 byte, 0x04-0x07…output), 3 data bytes, (total length 0x05)
  • 0x34: gain adjust: id (1 byte, 0x04-0x07…output), two data bytes, (total length 0x04)
  • 0x35: muting: id (1 byte, 0x04-0x07…output), one byte mute state, (total length 0x03)
  • 0x40: output meters (length 0x1c)

From host to DSP

The host (application) sends URB_INTERRUPT out packets to endpoint 2.

The packets can be requests, e.g. for the product string (type 0x13):

0000   1b 00 20 5a 5e b8 0d a1 ff ff 00 00 00 00 09 00
0010   00 01 00 07 00 02 01 40 00 00 00 10 02 00 01 01
0020   13 10 03 12 40 00 c8 c5 d6 06 d2 c5 d6 06 38 32
0030   d4 06 5f 4d 40 00 c8 c5 d6 06 5f 4d 40 00 c8 c5
0040   d6 06 bc fd fe 0c fd 47 40 00 c8 c5 d6 06 d2 c5
0050   d6 06 38 32 d4 06 d4 fd fe 0c d4

Here, the net length is 0x01, data type 0x13, trailing bytes 0x10 0x03 0x12.

From DSP to host

The DSP sends URB_INTERRUPT in packets from endpoint 1, e.g. output meters:

0000   1b 00 b0 e4 5c b6 0d a1 ff ff 00 00 00 00 09 00
0010   01 01 00 07 00 81 01 40 00 00 00 10 02 01 00 1c
0020   40 00 00 01 00 00 01 00 00 00 00 00 01 18 00 59
0030   1b 00 f1 1e 00 9f 1d 00 d8 00 00 00 10 03 b2 00
0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050   00 00 00 00 10 03 08 00 30 71 77
Data type 0x40 (meters)

The actual data bytes (length 0x1b = 27 bytes) are

00 00 01 00 00 01 00 00 00 00 00 01 18 00 59 1b 00 f1 1e 00 9f 1d 00 d8 00 00 00

other data chunks look like this:

00 00 01 00 00 01 00 00 00 00 00 01 1b 00 5e 1a 00 13 1a 00 dd 19 00 a2 00 00 00

00 00 01 00 00 01 00 00 00 00 00 01 1e 00 5a 1f 00 cc 20 00 b5 1f 00 ee 00 00 00

00 00 01 00 00 01 00 00 00 00 00 01 1d 00 8f 1c 00 82 1b 00 1d 1a 00 ca 00 00 00

00 00 01 00 00 01 00 00 00 00 00 01 2b 00 c1 29 00 df 27 00 c6 26 00 d1 00 00 00

We assume there are 4 input meters, 4 output meters, and 1 unknown extra slot, each 3 bytes.