USBhost_t36 MIDI losing midi note on / off events (Teensy 3.6) during modwheel change

But if you can craft a test program on Teensy 4.0, of course that's much better because it's consistent
Absolutely agree, the challange though is to make a testpattern that exactly mimics the Arturia.
Here is screendump of the latest fail with the Arturia:
Code:
20:06:56.886 -> Note On, ch = 1, note = 68, velocity = 127, NumNotes = 1
20:06:56.886 -> Note On, ch = 1, note = 66, velocity = 127, NumNotes = 2
20:06:56.886 -> Note On, ch = 1, note = 54, velocity = 127, NumNotes = 3
20:06:56.886 -> Note On, ch = 1, note = 53, velocity = 127, NumNotes = 4
20:06:56.886 -> Note On, ch = 1, note = 67, velocity = 127, NumNotes = 5
20:06:56.886 -> Note On, ch = 1, note = 65, velocity = 127, NumNotes = 6
20:06:56.886 -> Note On, ch = 1, note = 55, velocity = 127, NumNotes = 7
20:06:56.886 -> Note On, ch = 1, note = 60, velocity = 127, NumNotes = 8
20:06:56.886 -> Note On, ch = 1, note = 56, velocity = 127, NumNotes = 9
20:06:56.886 -> Note On, ch = 1, note = 62, velocity = 127, NumNotes = 10
20:06:56.886 -> Note On, ch = 1, note = 52, velocity = 127, NumNotes = 11
20:06:56.886 -> Note On, ch = 1, note = 57, velocity = 127, NumNotes = 12
20:06:56.886 -> Note On, ch = 1, note = 59, velocity = 127, NumNotes = 13
20:06:56.886 -> Note On, ch = 1, note = 58, velocity = 127, NumNotes = 14
20:06:56.886 -> Note Off, ch = 1, note = 58, velocity = 0, NumNotes = 13
20:06:57.075 -> Note Off, ch = 1, note = 56, velocity = 0, NumNotes = 12
20:06:57.075 -> Note Off, ch = 1, note = 59, velocity = 0, NumNotes = 11
20:06:57.075 -> Note Off, ch = 1, note = 57, velocity = 0, NumNotes = 10
20:06:57.075 -> Note Off, ch = 1, note = 62, velocity = 0, NumNotes = 9
20:06:57.075 -> Note Off, ch = 1, note = 64, velocity = 0, NumNotes = 8
20:06:57.075 -> Note Off, ch = 1, note = 68, velocity = 0, NumNotes = 7
20:06:57.075 -> Note Off, ch = 1, note = 52, velocity = 0, NumNotes = 6
[COLOR="#FF0000"]20:06:57.075 -> Note Off, ch = 1, note = 66, velocity = 0, NumNotes = 5[/COLOR]
20:06:57.075 -> Note Off, ch = 1, note = 67, velocity = 0, NumNotes = 4
20:06:57.122 -> Note Off, ch = 1, note = 65, velocity = 0, NumNotes = 3
20:06:57.122 -> Note Off, ch = 1, note = 60, velocity = 0, NumNotes = 2
20:06:57.122 -> Note Off, ch = 1, note = 54, velocity = 0, NumNotes = 1
20:06:57.122 -> Note Off, ch = 1, note = 55, velocity = 0, NumNotes = 0
20:06:57.122 -> Note Off, ch = 1, note = 53, velocity = 0, NumNotes = -1

The host sees 14 Note ON's but 15 Note OFF's [note 66 does not have an ON message].

Anyway, I will dig further...
Paul
 
I am only user of a T3.5 project with similar USB issues resolved by an intermediate USB hub...

Please start a new thread. Give specific details, ideally with photos of the setup. Show a complete program anyone can copy into Arduino IDE and upload to Teensy 3.5 to see the problem.

Just to be clear, Teensy 3.5 does not have USB host. Whatever issue you're experiencing can't possibly be related to USBHost_t36. This thread is the wrong place for any issue on Teensy 3.5.

Maybe you're asking here because you see so much activity and work happening on this thread? Maybe you believe starting a new thread will not get much attention? If you read this thread, you will see it is so active because test programs have been posted with clear steps to reproduce the problem. Whether your new thread and your issue will get similar attention depends mostly on you. If you just writing a message like this, saying you have a problem but no program to reproduce it, no details about the setup needed, then of course expect no significant effort. If you want me and others to get involved, you must give a program to reproduce the problem and clear instructions for any details needed.
 
The host sees 14 Note ON's but 15 Note OFF's [note 66 does not have an ON message].

Isn't the 2nd line a note 66 on message?

However, I don't see a note 64 on message...


Code:
20:06:56.886 -> Note On, ch = 1, note = 68, velocity = 127, NumNotes = 1
[COLOR="#FF0000"]20:06:56.886 -> Note On, ch = 1, note = 66, velocity = 127, NumNotes = 2[/COLOR]
20:06:56.886 -> Note On, ch = 1, note = 54, velocity = 127, NumNotes = 3
20:06:56.886 -> Note On, ch = 1, note = 53, velocity = 127, NumNotes = 4
20:06:56.886 -> Note On, ch = 1, note = 67, velocity = 127, NumNotes = 5
20:06:56.886 -> Note On, ch = 1, note = 65, velocity = 127, NumNotes = 6
20:06:56.886 -> Note On, ch = 1, note = 55, velocity = 127, NumNotes = 7
20:06:56.886 -> Note On, ch = 1, note = 60, velocity = 127, NumNotes = 8
20:06:56.886 -> Note On, ch = 1, note = 56, velocity = 127, NumNotes = 9
20:06:56.886 -> Note On, ch = 1, note = 62, velocity = 127, NumNotes = 10
20:06:56.886 -> Note On, ch = 1, note = 52, velocity = 127, NumNotes = 11
20:06:56.886 -> Note On, ch = 1, note = 57, velocity = 127, NumNotes = 12
20:06:56.886 -> Note On, ch = 1, note = 59, velocity = 127, NumNotes = 13
20:06:56.886 -> Note On, ch = 1, note = 58, velocity = 127, NumNotes = 14
20:06:56.886 -> Note Off, ch = 1, note = 58, velocity = 0, NumNotes = 13
20:06:57.075 -> Note Off, ch = 1, note = 56, velocity = 0, NumNotes = 12
20:06:57.075 -> Note Off, ch = 1, note = 59, velocity = 0, NumNotes = 11
20:06:57.075 -> Note Off, ch = 1, note = 57, velocity = 0, NumNotes = 10
20:06:57.075 -> Note Off, ch = 1, note = 62, velocity = 0, NumNotes = 9
[COLOR="#FF0000"]20:06:57.075 -> Note Off, ch = 1, note = 64, velocity = 0, NumNotes = 8[/COLOR]
20:06:57.075 -> Note Off, ch = 1, note = 68, velocity = 0, NumNotes = 7
20:06:57.075 -> Note Off, ch = 1, note = 52, velocity = 0, NumNotes = 6
[COLOR="#FF0000"]20:06:57.075 -> Note Off, ch = 1, note = 66, velocity = 0, NumNotes = 5[/COLOR]
20:06:57.075 -> Note Off, ch = 1, note = 67, velocity = 0, NumNotes = 4
20:06:57.122 -> Note Off, ch = 1, note = 65, velocity = 0, NumNotes = 3
20:06:57.122 -> Note Off, ch = 1, note = 60, velocity = 0, NumNotes = 2
20:06:57.122 -> Note Off, ch = 1, note = 54, velocity = 0, NumNotes = 1
20:06:57.122 -> Note Off, ch = 1, note = 55, velocity = 0, NumNotes = 0
20:06:57.122 -> Note Off, ch = 1, note = 53, velocity = 0, NumNotes = -1


Another question... is the problem always a missing note on? In other words, do you always end up with a negative NumNotes count?

If it's race condition, would seem likely to have 50-50 chance of losing either note on or note off...
 
Paul, if you read this thread you will notice that it is me who suggested using an intermediate USB hub that resolved the problem and that sparked the ongoing discussion.
 
I'm kinda wondering if Arturia sends unnecessary note off messages? When I get one in a couple days, will capture its USB packets...
 
Looks like note 64 off message is the one without a corresponding note on message
Yes correct, my mistake.

I'm kinda wondering if Arturia sends unnecessary note off messages? When I get one in a couple days, will capture its USB packets...

Yes, that thought crossed my mind as well a few days ago, but I checked the output of the Arturia and it seems OK. See message #56.

With respect to your other question: do you always end up with a negative NumNotes count? Most of the times I saw a negative NumNotes, but occasionally I've seen a positive NumNotes. But definitely not 50-50%.

Paul
 
Could be the timing of note on messages is different than note off messages. Or maybe the note on are just more likely to arrive when Teensy's buffers are empty.

Hopefully I'll have an Arturia soon so I can do more than just guess.
 
I'm kinda wondering if Arturia sends unnecessary note off messages? When I get one in a couple days, will capture its USB packets...

A hanging note on a synth means too few note off messages rather than too many. Remember also that the issue only arises when using the host port, and then is remedied by inserting a hub. I don't think the Arturia is at fault.
 
A hanging note on a synth means too few note off messages rather than too many. Remember also that the issue only arises when using the host port, and then is remedied by inserting a hub. I don't think the Arturia is at fault.

If I am not mistaken a USB-Midi Device these days is backwards compatible in most cases, so if you insert a cheap HUB, the Arturia may well use a low-power and low-speed mode compatible with Usb 1.1 standards... The teensy on the other hand has a full-blown 480Mbit host port.
 
My Arturia just arrived. Indeed I can easily reproduce the problem by just slamming several keys.

Here is the serial monitor output. I changed the note and velocity to hex, so it's easier to match up to the USB packets.

Code:
Note On, ch = 1, note = 41, velocity = 4D, NumNotes = 1
Note On, ch = 1, note = 43, velocity = 46, NumNotes = 2
Note On, ch = 1, note = 39, velocity = 5C, NumNotes = 3
Note On, ch = 1, note = 3B, velocity = 53, NumNotes = 4
Note On, ch = 1, note = 37, velocity = 56, NumNotes = 5
Note On, ch = 1, note = 3E, velocity = 5C, NumNotes = 6
Note On, ch = 1, note = 40, velocity = 5C, NumNotes = 7
Note On, ch = 1, note = 3C, velocity = 5D, NumNotes = 8
Note On, ch = 1, note = 35, velocity = 66, NumNotes = 9
Note On, ch = 1, note = 45, velocity = 45, NumNotes = 10
Note Off, ch = 1, note = 45, velocity = 0, NumNotes = 9
Note Off, ch = 1, note = 35, velocity = 0, NumNotes = 8
Note Off, ch = 1, note = 40, velocity = 0, NumNotes = 7
Note Off, ch = 1, note = 3C, velocity = 0, NumNotes = 6
Note Off, ch = 1, note = 3E, velocity = 0, NumNotes = 5
Note Off, ch = 1, note = 37, velocity = 0, NumNotes = 4
Note Off, ch = 1, note = 39, velocity = 0, NumNotes = 3
Note Off, ch = 1, note = 41, velocity = 0, NumNotes = 2
Note Off, ch = 1, note = 3B, velocity = 0, NumNotes = 1

In this case Teensy didn't receive the Note Off message for note 43.

Here are the packets my USB protocol analyzer captured.

screenshot.jpg

Looks like the Arturia never sent a Note Off message for 43. :(
 
Here's another screenshot of the USB packets with the Note On and Note Off messages highlighted.

screenshot.jpg

You can hopefully see the Arturia transmitted 10 Note On messages but only 9 Note Off messages.

I still haven't tested connected with a hub, or connect to my PC. Will try those shortly. I've literally only had this thing on my workbench less than an hour.
 
Ok, tested now with a hub between Teensy and Arturia. Can't reproduce the problem.

Also can't reproduce it with Arturia connected to my Linux desktop, listening with aseqdump -p "Arturia MiniLab mkII".

Very mysterious.....
 
Thinking (out loud) about this problem some more, the Arturia must be failing to transmit some MIDI messages (otherwise they would appear in the packet capture), but it's probably in response to something we're doing (or not doing, or not doing well enough) on the Teensy side.

My current theory is the Arturia probably has 1 or 2 packet buffers and if it wants to transmit another packet when the buffer(s) are full, it probably just discards the data rather than waiting. Or maybe it overwrites the waiting data. If this is really what's going on, it would explain why all attempts to reproduce it with Teensy 4.0 are unsuccessful. USB MIDI device code on Teensy 4.0 won't immediately drop outbound data if the USB packet buffers are full. But whatever firmware exists on Arturia probably does.

My guess is the missing Note Off message probably was generated during this time with the red circle, where no IN poll attempts occurred.

screenshot.jpg

Here is another run where 2 Note On messages were missing. It also has a substantial time where no polling occurred.

screenshot2.jpg

My gut feeling (guesswork) is the Arturia firmware is just throwing away data during those times, because we weren't polling rapidly enough.

I still need to compare with the PC and with a USB hub, but my guess is the Linux MIDI driver allocates a lot of buffers. The hub case is complicated because Arturia communicates with the Transaction Translator inside the hub (since it's 12 MBit/sec) and Teensy uses split transactions at 480 Mbit/sec to talk to the TT. But the TT probably implements as least a couple buffers. Later tonight or tomorrow I'll look more carefully at the polling behavior downstream of the TT.

Right now, I'm out of time for working on this... so just a rambling message to share my current thoughts and theories about this problem.
 
My gut feeling (guesswork) is the Arturia firmware is just throwing away data during those times, because we weren't polling rapidly enough
Thanks a lot for testing and sharing your thoughts on your findings so far. I concur with your plausible assumption.
I'm glad you own this pricey Beagle USB 480 Protocol Analyzer - it's nearly impossible to debug these kind of issues without such a device.

Will think further about your tests and get back if I have some ideas.

Thanks again,
Paul
 
Thinking (out loud) about this problem some more, the Arturia must be failing to transmit some MIDI messages (otherwise they would appear in the packet capture), but it's probably in response to something we're doing (or not doing, or not doing well enough) on the Teensy side.

My current theory is the Arturia probably has 1 or 2 packet buffers and if it wants to transmit another packet when the buffer(s) are full, it probably just discards the data rather than waiting. Or maybe it overwrites the waiting data. If this is really what's going on, it would explain why all attempts to reproduce it with Teensy 4.0 are unsuccessful. USB MIDI device code on Teensy 4.0 won't immediately drop outbound data if the USB packet buffers are full. But whatever firmware exists on Arturia probably does.

My guess is the missing Note Off message probably was generated during this time with the red circle, where no IN poll attempts occurred.

..

Here is another run where 2 Note On messages were missing. It also has a substantial time where no polling occurred.

..

My gut feeling (guesswork) is the Arturia firmware is just throwing away data during those times, because we weren't polling rapidly enough.

I still need to compare with the PC and with a USB hub, but my guess is the Linux MIDI driver allocates a lot of buffers. The hub case is complicated because Arturia communicates with the Transaction Translator inside the hub (since it's 12 MBit/sec) and Teensy uses split transactions at 480 Mbit/sec to talk to the TT. But the TT probably implements as least a couple buffers. Later tonight or tomorrow I'll look more carefully at the polling behavior downstream of the TT.

Right now, I'm out of time for working on this... so just a rambling message to share my current thoughts and theories about this problem.

Thanks again for looking at this Paul. If it's not a buffer number/size effect, is it possible the reason the problem doesn't arise when connecting the Arturia to a PC (and then back out to the Teensy non-host MIDI port) is due to the the same changes that occur when using a hub between the Arturia and host port? If so, and you can figure out what those changes are, maybe the T4.x host code be made to invoke the same behavior without the hub?
 
yes, if the host could be forced to run at 12mbit, the problems would most likely go away, since Arturia would switch to a different communication.
 
yes, if the host could be forced to run at 12mbit, the problems would most likely go away, since Arturia would switch to a different communication.

Well, I tried that, see message #32, but unfortunately that did eventually fail as well.

Paul
 
ok, the thread is getting a bit long to follow :) did you also try this after Paul posted the first fix?
 
did you also try this after Paul posted the first fix?

I just did, using Paul's fix from message #71.
Had to change MIDIDevice_BigBuffer midi1(myusb); to MIDIDevice midi1(myusb); to get forced full-speed to work.

But unfortunately forcing to full-speed did not help, still missing notes.

Paul
 
Looking further into the polling stuff and related timing, I read this article.
Using USBtreeview, I noticed that Arturia specifies a bInterval of '0'.

Arturia.png

If I read the USB 2.0 spec correct, that bInterval value should be between 1 and 16.
Could the host code have an problem with this bInterval = 0?

Paul
 
I'm glad you own this pricey Beagle USB 480 Protocol Analyzer - it's nearly impossible to debug these kind of issues without such a device.

Yep, it's pretty much essential for developing USB host.

A few open source projects have attempted to duplicate it at lower cost. So far none have comparable performance and software support. Maybe someday these will mature?

https://www.kickstarter.com/projects/bushing/openvizsla-open-source-usb-protocol-analyzer

https://www.crowdsupply.com/great-scott-gadgets/cynthion

https://github.com/ataradov/usb-sniffer



If I read the USB 2.0 spec correct, that bInterval value should be between 1 and 16.
Could the host code have an problem with this bInterval = 0?

bInterval isn't used for bulk or control endpoints. It only applies to interrupt and maybe isochronous (many complicated timing things regarding isochronous which I don't really know well).
 
Yep, it's pretty much essential for developing USB host
Looked at this USB protocol analyzer: usbpacketviewer but do not feel comfortable about the software... Price is ~$160...I guess you get what you pay for.

bInterval isn't used for bulk or control endpoints. It only applies to interrupt and maybe isochronous (many complicated timing things regarding isochronous which I don't really know well).
Just curious, what transfer/endpoint types are used for Arturia communication? I guess only Control?

Paul
 
Looked at this USB protocol analyzer: usbpacketviewer but do not feel comfortable about the software... Price is ~$160...I guess you get what you pay for.


Just curious, what transfer/endpoint types are used for Arturia communication? I guess only Control?

Paul

I can do some of it, using the Saleae Logic Analyzer, but it does not handle the 480mbs communications. I have a modified version of their USB LS/FS analyzer where I added support for High Level Analyzer(HLA) where I have it setup to output the packets that have data...
Which I discuss more over on the Saleae forum
https://discuss.saleae.com/t/usb-analyzer-how-well-does-it-work/2092/9?u=kurte

But nowhere as nice as the Beagle.
 
Back
Top