USB midi issues.

Status
Not open for further replies.

mark.winger

Active member
I have been working on a midi control surface using teensy 3.5, midi over usb. I actually have 3 devices, one with 16 motorized faders, 1 with 17 mortorized faders, and a third controlling about 75 rotary encoders, 100+ buttons with leds. They are basically separate devices connected to a usb hub so a single cable, 3 devices.

It works flawlessly on my laptop. But I need to run it on my desktop with all my audio devices. Running it on that system has problems. The laptop is a dual core 2ghz intel, but desktop is octal core 4ghz.

What happens is on the desktop it will work for a while then the usb interface locks up. My windows software gets blocked sending midi so the software hangs until I unplug the usb cable. I can then reconnect. The lock ups seem to occur after heavy midi traffic. Example, my software has fader groups where the moves of 1 fader are updated to other faders. So as I move 1 fader the software gets a bunch of positions and for each move I send a one to each of the other faders grouped. If get 30 updates, and have 5 additional faders in group, I send out 150 positions. (noise on a fader move can increase the number of updates alot too). Usually I can make a move like this a couple times before everything locks up.

I was thinking it was due to usb3 ports on the desktop (laptop has only 2.0), but the desktop has both usb 2.0 and 3.0 and both fail. It does seem to behave worse on some ports that others but not sure.

I checked the device drivers on the systems:
The laptop has microsoft generic usb audio 10.1.17763.1 but the desktop has 10.1.17143.1 and the date is about 6 months older on the desktop. I have been unable to figure out how get them to the same version. Windows says they are both up to date. ???

At first I thought the the usb/midi io buffers were getting overrun. When running on windows debugger I got it to consistantly hang at one place so I step through and see it send a short midi message(after many are sent successfully) and not return until I unplugged the cable. Since I was stepping one midi command at a time it is definitely not buffer overrun. The fact that the send message does not return made me suspicious of the drivers.

I am at a loss. Been working on this for days and the more I work it less I understand the problem. It's easy to reproduce but not always consistent.

Anyone seen anything like this or have any ideas how to track this down?
 
It does sound like too much midi being sent is overflowing the event buffer. Is there nothing in your code to limit the density of adjustment messages?

I'm not clear on the 'window debugger' comment...

The other possibility is that you've omitted the a read command to stop the DAW's outgoing midi from bunging up its event queue.

Code:
  // MIDI Controllers should discard incoming MIDI messages.
  while (usbMIDI.read()) {
  }
 
Last edited:
Thanks for the reply. I think I have resolved the problem. I turned out to be on the windows side, but not the drivers. It was a deadlock condition. When sending the data I was holding a lock on the message queue and other threads would receive midi data while the the original thread was still sending data. The receiver would lock and if the right conditions occurred, deadlock. I had to change a lot of code on the window side to avoid this but it now works.

Even though I have fixed the problem, I still don't completely understand the windows dead lock.
 
It turns out the problem is not resolved. I have tried this with multiple computers and it only fails on my main computer. I tried using a utility called sendmidi to confirm it is not my windows application. Using sendmidi I can send thousands of controllers and it never fails using my laptop. But using my desktop it fails quickly, often after just one or 2 controllers. I have tried this on 2 desktops and it fails on both. They are identical windows installs but intel vs amd.

I went back to look at drivers and updated to the latest windows install. Now the driver on the desktop is newer than the laptop but is still fails.

Any ideas on how to resolve this would be greatly appreciated.
 
It turns out the problem is not resolved. I have tried this with multiple computers and it only fails on my main computer. I tried using a utility called sendmidi to confirm it is not my windows application. Using sendmidi I can send thousands of controllers and it never fails using my laptop. But using my desktop it fails quickly, often after just one or 2 controllers. I have tried this on 2 desktops and it fails on both. They are identical windows installs but intel vs amd.

I went back to look at drivers and updated to the latest windows install. Now the driver on the desktop is newer than the laptop but is still fails.

Any ideas on how to resolve this would be greatly appreciated.

Try unplugging everything else using USB on the PC. Hard I know as that includes the mouse and keyboard, but my guess is that something is transmitting constantly whereas on a laptop most things are internal.
 
I am using a keyboard with touch pad so if I unplug it I have no input to reproduce the problem and that is the only other usb device plugged in.

I realized that the amd and intel systems may have a common problem since I cloned the hard drive from the intel to the amd system. So I have a newer system with a amd ryzen 12 core so I tried it on that system and it runs solid, I cannot reproduce it there. So next I will try a clean install on the amd system to see if the problem persists.
 
Had a very similar problem on an AMD quad core. Turned out that the culprit was a driver issue with the VIA USB3 host. I flashed the MoBoard with the latest Bios, disabled the on-board USB3 host, re-installed the OS and after testing, installed an Intel USB3 host board. Have had no midi problems since. The Via USB3 host is known to cause issues with Midi even if there are no devices physically plugged into one of it's ports.
 
Had a very similar problem on an AMD quad core. Turned out that the culprit was a driver issue with the VIA USB3 host. I flashed the MoBoard with the latest Bios, disabled the on-board USB3 host, re-installed the OS and after testing, installed an Intel USB3 host board. Have had no midi problems since. The Via USB3 host is known to cause issues with Midi even if there are no devices physically plugged into one of it's ports.
Thanks for the info. With my current amd system, things are pretty good but I still get the occasional lock up. I will pick up an Intel USB3 board and see if that completely resolves it. (will be out of town for the next month so it will be a while before I get to it.)
 
Thanks for the info. With my current amd system, things are pretty good but I still get the occasional lock up. I will pick up an Intel USB3 board and see if that completely resolves it. (will be out of town for the next month so it will be a while before I get to it.)
Looking for an intel usb card. I don't see any made by intel, only ones that say compatible with intel. Can you point me to the usb board you installed as a referemce?
 
Am out of town so can't peek inside the box, so checked supplier website and a Sunix USB 4300NS looks familiar - has a Renesas (NEC) uPD720201 controller.
Scratching grey haired head.., Sorry, I think I got my lines crossed here, was well over 6 months ago. Will be back in the den in about 12 hours so will take a look and report back. You might try removing your USB3 host drivers and disabling the hardware in CMOS, boot it up and let the OS get online for any updates then give the system a workout.
 
Following up on post #10. Have confirmed that the USB3 card is the Sunix USB 4300NS featuring the NEC uPD720201.
 
Status
Not open for further replies.
Back
Top