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 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?