Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 5 of 5

Thread: USB midi issues.

  1. #1

    USB midi issues.

    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?

  2. #2
    Senior Member oddson's Avatar
    Join Date
    Feb 2013
    Location
    Isle in the Salish Sea
    Posts
    1,138
    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 by oddson; 08-01-2019 at 05:21 AM.

  3. #3
    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.

  4. #4
    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.

  5. #5
    Junior Member
    Join Date
    Aug 2019
    Posts
    14
    Quote Originally Posted by mark.winger View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •