Received packets dropped occasionally when using on an AVR-NET-IO board

[bjoernbau]

First of all, thanks for this great library. Basically, I could get it running quite easily. I am using an AVR-NET-IO board with an ATmega664P (16MHz) and the EthernetENC library for driving the ENC28J60 network controller. The board is connected to a Windows 10 computer running the rtpMIDI driver from Tobias Erichsen.
Unfortunately I am faced with the problem that received packets get dropped occasionally (I handle the exceptionCallback and get the ReceivedPacketsDropped exception). This happens e.g. when playing a short midi score: Some midi note commands are received, some not while all of them are on the ethernet wire (checked with wireshark).
I'm not sure if the problem is caused by some bottleneck in the EthernetENC library, by the AppleMIDI library or the MIDI library. Is there a possibility to speed up the code of the AppleMIDI library? Is it possible to remove or deactivate the MIDI library used by the AppleMIDI library? I do not need the decoding of midi messages at all as I send the raw midi data directly to the serial port. I tried to comment out the MIDI.read() in the main loop but then the rtpMIDI driver cannot connect to the board at all.
Thanks for your help and best regards,
Björn

[lathoub]

This is the first release with checks on packet drops - and i'm not sure if the reporting of actual dropped packets is correct (so it might be reporting that packets are dropped, but that they actually did arrive) . If you see them on Wireshark, they should be visible on your device.

Can you count the midi message from your midi score, and compare with the amount that arrive?

I can't speed things up, but there are some events that you can use to get earlier access to the incoming MIDI messages (see the callback example: setHandleStartReceivedMidi, setHandleReceivedMidi and setHandleEndReceivedMidi)

[lathoub]

Alternatively, do you have another device (eg ESP32) to test on the same network setup?

[lathoub]

Also, in case of a suspected error, make sure you test against the latest source code here on GitHub and not against the released version available via the Arduino Library manager.

[bjoernbau]

Thanks for your reply.
I now had a closer look to the wireshark output and the incoming midi messages. The score has eight notes (thus creating eight note on and eight note off messages when played). They can be seen in wireshark:

No. Time Source Destination Protocol Length Info
209 56.717146 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note On (c=1, n=E2, v=95)
210 57.430087 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note Off (c=1, n=E2, v=95)
211 57.430279 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note On (c=1, n=G2, v=95)
213 58.144811 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note Off (c=1, n=G2, v=95)
214 58.145128 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note On (c=1, n=A2, v=95)
215 58.849437 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note Off (c=1, n=A2, v=95)
216 58.849626 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note On (c=1, n=D3, v=95)
218 59.561362 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note Off (c=1, n=D3, v=95)
219 59.561542 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note On (c=1, n=E3, v=95)
221 60.260123 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note Off (c=1, n=E3, v=95)
222 60.260301 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note On (c=1, n=G3, v=95)
225 60.973536 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note Off (c=1, n=G3, v=95)
226 60.973739 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note On (c=1, n=A3, v=95)
227 61.671559 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note Off (c=1, n=A3, v=95)
228 61.671762 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note On (c=1, n=E3, v=95)
231 62.386917 192.168.1.1 192.168.1.2 RTP-MIDI 58 Note Off (c=1, n=E3, v=95)

I already use the HandleReceivedMidi callback to get the raw bytes. I get the following output on my serial debug console (the hex values are the bytes the HandleReceivedMidi callback gives me):

*** ReceivedPacketsDropped 65511
0x80 0x28 0x5F
*** ReceivedPacketsDropped 65535
0x80 0x2B 0x5F
0x90 0x2D 0x5F
0x80 0x2D 0x5F
*** ReceivedPacketsDropped 65535
0x80 0x32 0x5F
*** ReceivedPacketsDropped 65535
0x80 0x34 0x5F
*** ReceivedPacketsDropped 65535
0x80 0x37 0x5F
*** ReceivedPacketsDropped 65535
0x80 0x39 0x5F
*** ReceivedPacketsDropped 65535
0x80 0x34 0x5F

As can be seen, all midi off messages are delivered, but only one midi on message. When there should be a midi on message I get the ReceivedPacketsDropped exception instead.

Next, I will check the behaviour using a ESP01 module and give a feedback soon.

[bjoernbau]

Also, in case of a suspected error, make sure you test against the latest source code here on GitHub and not against the released version available via the Arduino Library manager.

I checked the versions. The version from the Arduino library manager is equal to the latest version on GitHub.

[lathoub]

Also, in case of a suspected error, make sure you test against the latest source code here on GitHub and not against the released version available via the Arduino Library manager.

I checked the versions. The version from the Arduino library manager is equal to the latest version on GitHub.

What i meant was: don't use the release version, use a clone or copy of the latest source code (i have made modifications to the source code after the release)

[lathoub]

Something is off, the fact that its always the note On is dropped (dropping packets should be totally random, due to network conditions - in a home network (?) packets are rarely/never dropped).

Also, the sequenceNr is 65535 or 0xFFFF and looks like the sequenceNr uint16_t does not roll over.

Arduino-AppleMIDI-Library/src/AppleMIDI.hpp

Lines 1015 to 1020 in 3e2e2a6

	if (pParticipant->receiveSequenceNr + 1 != rtp.sequenceNr) {
	#ifdef USE_EXT_CALLBACKS
	if (nullptr != _exceptionCallback)
	_exceptionCallback(ssrc, ReceivedPacketsDropped, pParticipant->receiveSequenceNr + 1 - rtp.sequenceNr);
	#endif

[lathoub]

Something is off, the fact that its always the note On is dropped (dropping packets should be totally random, due to network conditions - in a home network (?) packets are rarely/never dropped).

0x90 0x2D 0x5F
There is 1 noteOn in the series, so not always

Your computer has ip 192.168.1.1 and your Arduino 192.168.1.2 - what does your network topology look like? Do you use a router with DHCP? (192.168.1.1 is typically used by a router, not a computer).

[lathoub]

Can you add to your sketch

#define SerialMon Serial
#define APPLEMIDI_DEBUG SerialMon

in AppleMIDI.hpp:

DBG("pParticipant->receiveSequenceNr", pParticipant->receiveSequenceNr);
DBG("rtp.sequenceNr", rtp.sequenceNr);

before

Arduino-AppleMIDI-Library/src/AppleMIDI.hpp

Line 1015 in 3e2e2a6

if (pParticipant->receiveSequenceNr + 1 != rtp.sequenceNr) {

and replace

Arduino-AppleMIDI-Library/src/AppleMIDI.hpp

Line 1015 in 3e2e2a6

if (pParticipant->receiveSequenceNr + 1 != rtp.sequenceNr) {

with

     if ((uint16_t)(pParticipant->receiveSequenceNr + 1)) != rtp.sequenceNr) { 

[bjoernbau]

Also, in case of a suspected error, make sure you test against the latest source code here on GitHub and not against the released version available via the Arduino Library manager.

I checked the versions. The version from the Arduino library manager is equal to the latest version on GitHub.

What i meant was: don't use the release version, use a clone or copy of the latest source code (i have made modifications to the source code after the release)

I compared the code from the main git branch to the release in Arduino (v3.0.0), they are equal. There are only minimal differences in the library.properties and README.md files.

[bjoernbau]

Something is off, the fact that its always the note On is dropped (dropping packets should be totally random, due to network conditions - in a home network (?) packets are rarely/never dropped).

Also, the sequenceNr is 65535 or 0xFFFF and looks like the sequenceNr uint16_t does not roll over.

Arduino-AppleMIDI-Library/src/AppleMIDI.hpp

Lines 1015 to 1020 in 3e2e2a6

	if (pParticipant->receiveSequenceNr + 1 != rtp.sequenceNr) {
	#ifdef USE_EXT_CALLBACKS
	if (nullptr != _exceptionCallback)
	_exceptionCallback(ssrc, ReceivedPacketsDropped, pParticipant->receiveSequenceNr + 1 - rtp.sequenceNr);
	#endif

I think the calculation of the dropped packets needs to be reversed to:
_exceptionCallback(ssrc, ReceivedPacketsDropped, rtp.sequenceNr - pParticipant->receiveSequenceNr - 1);
With this modification, I get the correct number of dropped packets.

[bjoernbau]

Your computer has ip 192.168.1.1 and your Arduino 192.168.1.2 - what does your network topology look like?

Correct, I use a direct ethernet cable between the computer and the board.
Maybe the EthernetENC library for driving the ENC28J60 requires so much computational power so it cannot handle all packets, but this would be quite weird.

[bjoernbau]

Can you add to your sketch

I did it and get the following result (with the reversed calculation of the dropped packets). There are several midi commands before and after the notes. This is caused by the score software. And again, there is just one note on command comming through.

Booting
Ethernet cable is not connected.
OK, now make sure you an rtpMIDI session that is Enabled
Add device named Arduino with Host 192.168.1.2 Port 5004 (Name AppleMIDI-Arduino )
Then press the Connect button
Then open a MIDI listener and monitor incoming notes
Connected to session HP-ProBook-450-G2
pParticipant->receiveSequenceNr 255
rtp.sequenceNr 304
*** ReceivedPacketsDropped 48
0xB9 0x00 0x7F
pParticipant->receiveSequenceNr 304
rtp.sequenceNr 306
*** ReceivedPacketsDropped 1
0xC9 0x00
pParticipant->receiveSequenceNr 306
rtp.sequenceNr 311
*** ReceivedPacketsDropped 4
0xB9 0x5F 0x00
pParticipant->receiveSequenceNr 311
rtp.sequenceNr 316
*** ReceivedPacketsDropped 4
0xB9 0x06 0x0C
pParticipant->receiveSequenceNr 316
rtp.sequenceNr 321
*** ReceivedPacketsDropped 4
0xB1 0x00 0x00
pParticipant->receiveSequenceNr 321
rtp.sequenceNr 326
*** ReceivedPacketsDropped 4
0xB0 0x0A 0x40
pParticipant->receiveSequenceNr 326
rtp.sequenceNr 331
*** ReceivedPacketsDropped 4
0xB1 0x5B 0x00
pParticipant->receiveSequenceNr 331
rtp.sequenceNr 336
*** ReceivedPacketsDropped 4
0xB0 0x0B 0x7F
pParticipant->receiveSequenceNr 336
rtp.sequenceNr 341
*** ReceivedPacketsDropped 4
0xB1 0x64 0x00
pParticipant->receiveSequenceNr 341
rtp.sequenceNr 346
*** ReceivedPacketsDropped 4
0xB9 0x00 0x7F
pParticipant->receiveSequenceNr 346
rtp.sequenceNr 348
*** ReceivedPacketsDropped 1
0xB9 0x07 0x7F
pParticipant->receiveSequenceNr 348
rtp.sequenceNr 353
*** ReceivedPacketsDropped 4
0xB9 0x5C 0x00
pParticipant->receiveSequenceNr 353
rtp.sequenceNr 358
*** ReceivedPacketsDropped 4
0xB9 0x26 0x00
pParticipant->receiveSequenceNr 358
rtp.sequenceNr 363
*** ReceivedPacketsDropped 4
0xB0 0x07 0x7F
pParticipant->receiveSequenceNr 363
rtp.sequenceNr 368
*** ReceivedPacketsDropped 4
0xB1 0x5D 0x00
pParticipant->receiveSequenceNr 368
rtp.sequenceNr 373
*** ReceivedPacketsDropped 4
0xB0 0x5C 0x00
pParticipant->receiveSequenceNr 373
rtp.sequenceNr 383
*** ReceivedPacketsDropped 9
0xB0 0x26 0x00
pParticipant->receiveSequenceNr 383
rtp.sequenceNr 435
*** ReceivedPacketsDropped 51
0xB2 0x7B 0x00
pParticipant->receiveSequenceNr 435
rtp.sequenceNr 453
*** ReceivedPacketsDropped 17
0x80 0x28 0x5F
pParticipant->receiveSequenceNr 453
rtp.sequenceNr 455
*** ReceivedPacketsDropped 1
0x80 0x2B 0x5F
pParticipant->receiveSequenceNr 455
rtp.sequenceNr 457
*** ReceivedPacketsDropped 1
0x80 0x2D 0x5F
pParticipant->receiveSequenceNr 457
rtp.sequenceNr 458
0x90 0x32 0x5F
pParticipant->receiveSequenceNr 458
rtp.sequenceNr 459
0x80 0x32 0x5F
pParticipant->receiveSequenceNr 459
rtp.sequenceNr 461
*** ReceivedPacketsDropped 1
0x80 0x34 0x5F
pParticipant->receiveSequenceNr 461
rtp.sequenceNr 463
*** ReceivedPacketsDropped 1
0x80 0x37 0x5F
pParticipant->receiveSequenceNr 463
rtp.sequenceNr 465
*** ReceivedPacketsDropped 1
0x80 0x39 0x5F
pParticipant->receiveSequenceNr 465
rtp.sequenceNr 467
*** ReceivedPacketsDropped 1
0x80 0x34 0x5F
pParticipant->receiveSequenceNr 467
rtp.sequenceNr 471
*** ReceivedPacketsDropped 3
0xB3 0x7B 0x00
pParticipant->receiveSequenceNr 471
rtp.sequenceNr 476
*** ReceivedPacketsDropped 4
0xB8 0x7B 0x00
pParticipant->receiveSequenceNr 476
rtp.sequenceNr 481
*** ReceivedPacketsDropped 4
0xBD 0x7B 0x00
pParticipant->receiveSequenceNr 481
rtp.sequenceNr 486
*** ReceivedPacketsDropped 4
0xB2 0x7B 0x00
pParticipant->receiveSequenceNr 486
rtp.sequenceNr 491
*** ReceivedPacketsDropped 4
0xB7 0x7B 0x00
pParticipant->receiveSequenceNr 491
rtp.sequenceNr 496
*** ReceivedPacketsDropped 4
0xBC 0x7B 0x00
pParticipant->receiveSequenceNr 496
rtp.sequenceNr 501
*** ReceivedPacketsDropped 4
0xE0 0x00 0x40
pParticipant->receiveSequenceNr 501
rtp.sequenceNr 502
0xB9 0x00 0x7F
pParticipant->receiveSequenceNr 502
rtp.sequenceNr 506
*** ReceivedPacketsDropped 3
0xB9 0x0A 0x40
pParticipant->receiveSequenceNr 506
rtp.sequenceNr 511
*** ReceivedPacketsDropped 4
0xB9 0x0B 0x7F
pParticipant->receiveSequenceNr 511
rtp.sequenceNr 516
*** ReceivedPacketsDropped 4
0xB0 0x00 0x00
pParticipant->receiveSequenceNr 516
rtp.sequenceNr 521
*** ReceivedPacketsDropped 4
0xC1 0x19
pParticipant->receiveSequenceNr 521
rtp.sequenceNr 526
*** ReceivedPacketsDropped 4
0xB0 0x5D 0x00
pParticipant->receiveSequenceNr 526
rtp.sequenceNr 531
*** ReceivedPacketsDropped 4
0xB1 0x5F 0x00
pParticipant->receiveSequenceNr 531
rtp.sequenceNr 544
*** ReceivedPacketsDropped 12
0xB0 0x7B 0x00
pParticipant->receiveSequenceNr 544
rtp.sequenceNr 548
*** ReceivedPacketsDropped 3
0xB2 0x7B 0x00
pParticipant->receiveSequenceNr 548
rtp.sequenceNr 553
*** ReceivedPacketsDropped 4
0xB4 0x79 0x00
pParticipant->receiveSequenceNr 553
rtp.sequenceNr 558
*** ReceivedPacketsDropped 4
0xB7 0x7B 0x00
pParticipant->receiveSequenceNr 558
rtp.sequenceNr 563
*** ReceivedPacketsDropped 4
0xB9 0x79 0x00
pParticipant->receiveSequenceNr 563
rtp.sequenceNr 568
*** ReceivedPacketsDropped 4
0xBC 0x7B 0x00
pParticipant->receiveSequenceNr 568
rtp.sequenceNr 573
*** ReceivedPacketsDropped 4
0xBE 0x79 0x00