search

sgorpi / midex8

Linux driver for Steinberg's MIDEX8
GNU General Public License v3.0
3 stars 3 forks source link

Unknown type of MIDEX8 #3

Open ykcirtsyb opened 3 years ago

ykcirtsyb commented 3 years ago

Hi, I have three pieces of MIDEX8 and I try to put them into operation using this driver.

My HW:

My SW:

midex8 Driver

The build of the driver went well with a few warnings, but it is loaded in the kernel and functional.

List of MIDEXs without drivers installed:

MIDEX A + B (A Dev = 8/ B Dev = 9)
pi@raspberrypi:~ $ dmesg
[20072.102162] usb 1-1.1.2: new full-speed USB device number 8 using dwc_otg
[20077.275877] usb 1-1.1.2: New USB device found, idVendor=0a4e, idProduct=1010, bcdDevice= 2.01
[20077.275899] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[20077.275916] usb 1-1.1.2: Product: Steinberg MIDEX 8 (r2)
[20077.275931] usb 1-1.1.2: Manufacturer: Steinberg

pi@raspberrypi:~ $ lsusb
Bus 001 Device 008: ID 0a4e:1010 Steinberg Soft-und Hardware GmbH

pi@raspberrypi:~ $ usb-devices
T:  Bus=01 Lev=03 Prnt=03 Port=01 Cnt=02 Dev#=  8 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0a4e ProdID=1010 Rev=02.01
S:  Manufacturer=Steinberg
S:  Product=Steinberg MIDEX 8 (r2)
C:  #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=400mA
I:  If#=0x0 Alt= 0 #EPs= 5 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
MIDEX C
pi@raspberrypi:~ $ dmesg
[20386.463936] usb 1-1.1.2: new full-speed USB device number 14 using dwc_otg
[20386.595475] usb 1-1.1.2: New USB device found, idVendor=0a4e, idProduct=1000, bcdDevice= 0.01
[20386.595489] usb 1-1.1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0

pi@raspberrypi:~ $ lsusb
Bus 001 Device 014: ID 0a4e:1000 Steinberg Soft-und Hardware GmbH

pi@raspberrypi:~ $ usb-devices
T:  Bus=01 Lev=03 Prnt=03 Port=01 Cnt=02 Dev#= 14 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  1
P:  Vendor=0a4e ProdID=1000 Rev=00.01
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#=0x0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

So, as you can see, MIDEX A and B are both same, but MIDEX C is different. It has a slightly different look, but especially there is a different PCB and USB chip inside.

List of MIDEXs with drivers installed:

MIDEX A + B
pi@raspberrypi:~ $ dmesg
[  105.714357] usb 1-1.1.2: new full-speed USB device number 10 using dwc_otg
[  110.928082] usb 1-1.1.2: New USB device found, idVendor=0a4e, idProduct=1010, bcdDevice= 2.01
[  110.928104] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  110.928120] usb 1-1.1.2: Product: Steinberg MIDEX 8 (r2)
[  110.928136] usb 1-1.1.2: Manufacturer: Steinberg
[  110.929330] usb 1-1.1.2: snd-usb-midex: Firmware update not implemented.
[  110.929349] usb 1-1.1.2: snd-usb-midex: Recognized MIDEX8 at usb-3f980000.usb-1.1.2
[  111.464315] usb 1-1.3: new full-speed USB device number 11 using dwc_otg
[  116.608081] usb 1-1.3: New USB device found, idVendor=0a4e, idProduct=1010, bcdDevice= 2.01
[  116.608104] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  116.608120] usb 1-1.3: Product: Steinberg MIDEX 8 (r2)
[  116.608135] usb 1-1.3: Manufacturer: Steinberg
[  116.609324] usb 1-1.3: snd-usb-midex: Firmware update not implemented.
[  116.609345] usb 1-1.3: snd-usb-midex: Recognized MIDEX8 at usb-3f980000.usb-1.3

pi@raspberrypi:~ $ amidi -l
Dir Device    Name
IO  hw:1,0,0  MIDEX Port 1
IO  hw:1,0,1  MIDEX Port 2
IO  hw:1,0,2  MIDEX Port 3
IO  hw:1,0,3  MIDEX Port 4
IO  hw:1,0,4  MIDEX Port 5
IO  hw:1,0,5  MIDEX Port 6
IO  hw:1,0,6  MIDEX Port 7
IO  hw:1,0,7  MIDEX Port 8
IO  hw:2,0,0  MIDEX Port 1
IO  hw:2,0,1  MIDEX Port 2
IO  hw:2,0,2  MIDEX Port 3
IO  hw:2,0,3  MIDEX Port 4
IO  hw:2,0,4  MIDEX Port 5
IO  hw:2,0,5  MIDEX Port 6
IO  hw:2,0,6  MIDEX Port 7
IO  hw:2,0,7  MIDEX Port 8
MIDEX C - does not work. Of course, its ID is not in the module.

Is it possible to add it?

Best regards, David Bystricky

sgorpi commented 3 years ago

Hi David,

I've just added a branch with the updates to support your "MIDEX C" with PID 1000. Please see/download it at https://github.com/sgorpi/midex8/tree/new_midex8_pid1000 and let me know if it works! If so then I'll merge the branch to master.

Nice to see the other two devices are working on a Raspberry Pi though :D what's the use-case for so many midi ports?

Best regards, Hedde // Sgorpi

ykcirtsyb commented 3 years ago

Hi Hedde,

thanks for your work, but unfortunately this does not work. Raspi crashes immediately after connecting "MIDEX C". According to the information from dmesg, a USB device was connected, but there was a problem with snd_usb_midex in the sb_midex_drv_probe function.

Best regards, David

sgorpi commented 3 years ago

Hi David,

I've added a new commit with an extra nullpointer check, as I noticed in your initial lsusb/dmesg the midex C didn't show it's product name. I hope that resolves the crash... If not, then it'll be very difficult to debug it. Are you in a position to get raw usb logs (with for example wireshark) from a windows machine with official drivers?

I currently have very limited time on my hands due to the corona situation and family, so I can't promise much...

Best, Hedde

ykcirtsyb commented 3 years ago

Hi Hedde, this is perfect. At this point, the driver recognizes the device and tries to communicate with it, but another problem has appeared.

$ dmesg
///
[531.212818] usb 1-1.3: new full-speed USB device number 3 using ehci-pci
[531.321456] usb 1-1.3: New USB device found, idVendor = 0a4e, idProduct = 1000, bcdDevice = 0.01
[531.321462] usb 1-1.3: New USB device strings: Mfr = 0, Product = 0, SerialNumber = 0
[531.322096] usb 1-1.3: snd-usb-midex: Recognized MIDEX:
[531.322354] usb 1-1.3: snd-usb-midex: usb_submit_urb: -2 at sb_midex_init_device
[531.322361] usb 1-1.3: snd-usb-midex: error during probing
[531.322394] snd-usb-midex: probe of 1-1.3: 1.0 failed with error -2
///

It doesn't like the initialization data? Or something.

My opinion:

As I wrote before, in this type of midex, other connections and different uC are used. This uC does not have a large EEPROM memory with firmware, and according to the first byte in memory, its bootloader waits for data sent from the host.

I verified this with VM Win10

But without this Linux - Win reconnection it doesn work. So fully initialized device with PID 0x1001 work and empty device with PID 0x1000 not.

I tried to record USB communication with the original Win driver. MIDEX_C.pcapng.zip

Thank you for your time. I try to get into it myself, but these things about USB and kernel modules are completely new to me, so I'm pretty lost in it. But it's a challenge.

If I succeed, I will return the meaning of these three converters and try to connect them to the rest of our studio via RTP MIDI. But this is another chapter.

Best regards, David

sgorpi commented 3 years ago

Hi David,

Good that it now doesn't crash at least hehe. Thanks for the analysis effort! The problem becomes more clear... I hadn't implemented firmware updates because mine also worked without. But indeed I noticed the windows driver updates firmware and then it lists with pid 1001. This firmware will stay active until a power cycle I believe. Maybe time to implement the firmware update then... Given my current availability that won't be before summer though... Hope you can wait that long...

Best, Hedde

ykcirtsyb commented 3 years ago

Hi Hedde, If it succeeds, it will be great. For now, I will try to complete my plan with at least two functional converters.

If there's anything else I can do to help you, let me know. I'll try to help as best I can.

ykcirtsyb commented 3 years ago

Hi Hedde, I found some free time and I managed to find a sequence of data sent by the original Win driver to update the firmware in Midex. fw_data.json.zip

I replicated the process using a Python script and it really works for all three units. After sending the data, it is immediately reported as a new device with PID 1001 for the entire time of connection or power supply.

So I temporarily solved my situation and I have a Python script that checks the newly connected USB devices, if it detects some of the not updated Midex, it sends an FW update. Then the driver recognize them.

It's a mix of a kernel module with a user-space script, but it works. For now, I don't know much about how your module code works, so I don't dare add the FW update there.

Best regards, David

sgorpi commented 3 years ago

Hi David,

Nice work-around solution!

If you're interested, you're welcome to contribute the python script to this repository, maybe someone else is helped with it until I manage to find time to implement the process in the driver. I'll let you know when I have updated the driver.

Wkr, Hedde

ruigominho commented 3 years ago

Hello,

I bought a cheap second-hand Steinberg Midex 8 after seeing this driver was available here (thanks Hedde for you work and for sharing it) Unfortunately I ran into the same problem described here, PID 1000...

dmesg: [ 172.741847] usb 1-8: snd-usb-midex: Recognized MIDEX: [ 172.742017] usb 1-8: snd-usb-midex: usb_submit_urb: -2 at sb_midex_init_device [ 172.742021] usb 1-8: snd-usb-midex: error during probing [ 172.742029] snd-usb-midex: probe of 1-8:1.0 failed with error -2

@ykcirtsyb if you care to share your python script I would gladly try and use it for my unit, at least as a workaround solution...

Thanks

ykcirtsyb commented 3 years ago

Hi @ruigominho you can find my script here.

I originally wrote it just for testing, but in the end it works perfectly for me. So feel free to try and if it helps, I'll be happy.

ruigominho commented 3 years ago

Hi David,

Thank you very much, it works now!

I will keep an eye on this repository hoping that Hedde finds the time to implement the firmware update feature. I have a programming background but I feel now so rusty/lazy that I would take me eons to get up to shape now :)

Thank you both for your work and for sharing it

patrykwegrzyn commented 3 years ago

Im experiencing the same issue here

patrykwegrzyn commented 3 years ago

For my own convenience I decided to re implement @ykcirtsyb solution in go as a systemd service. If you are interested you can find it here Obviously all creds go @ykcirtsyb for doing spectacular job on packet capture and original solution