Received packets dropped occasionally when using on an AVR-NET-IO board #100
Comments
|
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 |
|
Alternatively, do you have another device (eg ESP32) to test on the same network setup? |
|
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. |
|
Thanks for your reply. No. Time Source Destination Protocol Length Info 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 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. |
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) |
|
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 Arduino-AppleMIDI-Library/src/AppleMIDI.hpp Lines 1015 to 1020 in 3e2e2a6 |
Your computer has ip |
|
Can you add to your sketch in AppleMIDI.hpp: before Arduino-AppleMIDI-Library/src/AppleMIDI.hpp Line 1015 in 3e2e2a6 and replace Arduino-AppleMIDI-Library/src/AppleMIDI.hpp Line 1015 in 3e2e2a6 with |
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. |
I think the calculation of the dropped packets needs to be reversed to: |
Correct, I use a direct ethernet cable between the computer and the board. |
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 |
I now checked the behaviour using an ESP01. It behaves much better. When starting the score software (where the midi configuration commands get sent), there are some dropped packets (maybe due to wifi?). But when the midi notes are sent, 7 note on and all 8 note off commands are received. Booting |
|
I'm seeing the same drops when I have the callbacks print to serial (using So can you try to remove the debugging statements, only keeping the (tested on a wired wESP32) |
|
Using an ESP32, on a slow wifi network, i see occasional drops - but not on a wired network. |
|
added |
Thanks for your support. I am quite not sure where to debug further. Maybe I will import the sketch to Atmel Studio as this makes debugging easier and will take a closer look to the ethernet library. |
After updating my code base to the master, I noticed that I do not get any exception callback at all. pParticipant->firstMessageReceived is initialised to true, but never gets set to false (it will never enter the following statement): Arduino-AppleMIDI-Library/src/AppleMIDI.hpp Lines 1015 to 1022 in 84f3dca I think the code snippet needs to be modified to: |
|
Thanks for the fox - uploaded to master (and contributed to you) |
|
I'm not able to reproduce dropped packets on a wESP32 (Ethernet). |
|
Correction - i do get the drops now as well :-( |
|
packets are read here: Arduino-AppleMIDI-Library/src/AppleMIDI.hpp Lines 43 to 58 in cb72859 similarly for the control packets. I'm starting to think the packets are dropped here (use/order of |
|
Having increased the Arduino-AppleMIDI-Library/src/AppleMIDI.h Lines 189 to 220 in cb72859 |
|
I am not sure if I can support you with the current debugging. If so, please let me know. |
|
i can now consistently reproduce the issue:
Playing the MID file thru MIDI-OX -> rtpMIDI issues 15 seperate MIDI messages at once - each in their own UDP packet/frame. This library is single threaded and reading the UDP packets and parsing happens in the same thread - if the program does not execute fast enough, packets will be dropped - if the are sent as seperate messages. rtpMIDI does provide the mechanism to pack them all into 1 rtpMIDI message (multiple per packet), but somehow MIDI-OX/rtpMIDI1.1.14 do not do that. (I need to check if I play the same MID file from MacOS combines the messages) So, what to do here? The library has been build assuming multiple MIDI messages per packet (when intended to be played at the same time) and minimum memory footprint. From the above, it looks like i need to optimize the parser for speed (currently I do not have the time to do that, so all help is welcome) |
|
When I play the same MID file on MacOS (using Aria Maestosa) I get 0 (zero) dropped packets, because the MIDI messages that are send at the same time, are put into the same packet - and not in seperate packages on Windows when using rtpMIDI 1.1.14. Albeit rtpMIDI 1.1.14 is not wrong, it should put MIDI messages that are send at the same time in 1 UDP packet (see spec) On MacOS:
On Windows using rtp .1.114
I will try with another MID player than MIDI OX - trying to understand if its MIDI-OX or rtpMIDI 1.1.14 |
|
Aria Maestosa is also available on Windows. When playing the same MID file, again, each MIDI message goes into a separate rtpMIDI packet, not using the multiple MIDI messages in 1 MIDI section
On MacOS, all Control Change and Program Changes are put into 1 rtpMIDI packet
|
I had a short look to the EthernetENC library I use to drive the ENC28J60 network controller. The library configures 2048 Bytes of receive buffer in the ENC28J60. At first glance this should be sufficient to keep some packets while the AppleMIDI library is busy.
I could write Tobias Erichsen an email to ask him about his opinion if the rtpMIDI driver works properly. Maybe he is not aware about the fact that putting multiple messages into one data package would be preferable. What do you think? |
|
When looking to this screenshot the question comes to me why parseDataPackets takes so much longer when a received packet got dropped compared to when it was processed properly. I think that's strange. I can have a closer look to your library and do some more debugging at the weekend. |
I also wondered that. When i remove the debug message in the handler, the time is similar to the other messages |
|
I have created another branch (v3.1) to work in |
|
New data point: Teensy 4.1 with Ethernet Kit: no dropped packets using rtpMIDI 1.1.14 |
|
delete branch v3.1 - latest changes to master. |
Unfortunatly I do not notice any difference. I still get dropped packages, even when using the sample you linked before. I attached a simple Midi file I used until now: Sample.zip |
|
With the latest code in the Master branch, i can play your sample MID file (zipped above) in TuxGuitar without a single dropped package on:
Only on a ESP32 I get dropped packages. Moving to AsyncUDP is a big change in the code, not sure if I want to do that. The ESP8266 does not drop any packge, whilst the ESP32 drops a lot - i can't explain it. I reverted back to reading 1 packet and parse directly if (readDataPackets()) // from socket into dataBuffer
parseDataPackets(); // from dataBuffer into inMidiBuffer
if (readControlPackets()) // from socket into controlBuffer
parseControlPackets(); // from controlBuffer to AppleMIDIwhich allows for really small buffers: 24 bytes for UDP, 64 for the MIDI messages. The alternative approach, reading as much packets as possible first, then parse needs much more memory (256 in stead of 64) while (readDataPackets()) // from socket into dataBuffer
parseDataPackets(); // from dataBuffer into inMidiBuffer
while (readControlPackets()) // from socket into controlBuffer
parseControlPackets(); // from controlBuffer to AppleMIDI |
|
Hi @lathoub By now, I think the EthernetENC library takes too much computation power, so the AppleMidi library does not get enough cpu time to run properly. A big disadvantage of the ENC28J60 network controller is that the whole IP stack needs to be done in software, and that seems to become obvious here. I will try to get a shield with a W5100 or W5500 network controller as this will reduce the cpu load significantly. I will report as soon as I will have new knowledge. Thanks again for your support so far and many greetings. |
|
I also tried with this one W5500 based over SPI interface without dropping packets |
That is good to know. I just ordered this type of board yesterday evening. |
|
I added an additional update, reading packets before parsing then. It helps, but does not resolve the issue entirely (the issue remains that rtpMidi send 1 packet per MIDI message, in stead of the optimized method of putting them together in 1 packet - see spec MIDI Command Section) I also noticed that playing the MIDI file via MIDI-OX never drops a packet, TuxGuitar and Area occasionaly drop a package. Each send different headers and footers. Hardware: MKR ZERO + ETH field, ESP32, ESP32 + W5500 over SPI @bjoernbau can you try playing the MIDI file with MIDI-OX on your ENC28J60 MIDI-OX output (never drops packets)
TuxGuitar
Aria
|
|
The default number of sockets on a W5500 is 8 with 2K buffers. Lowering the max amount of sockets, allow for larger buffers. The shipping Ethernet library does not allow setting the Using the Ethernet3 library, the number of sockets for the W5500 can be defined Lowering the See the ESP32 + W5500 example how it works |
|
Modify the shipping Ethernet library, and change from: // Configure the maximum number of sockets to support. W5100 chips can have
// up to 4 sockets. W5200 & W5500 can have up to 8 sockets. Several bytes
// of RAM are used for each socket. Reducing the maximum can save RAM, but
// you are limited to fewer simultaneous connections.
#if defined(RAMEND) && defined(RAMSTART) && ((RAMEND - RAMSTART) <= 2048)
#define MAX_SOCK_NUM 4
#else
#define MAX_SOCK_NUM 8
#endifto: #ifndef MAX_SOCK_NUM
// Configure the maximum number of sockets to support. W5100 chips can have
// up to 4 sockets. W5200 & W5500 can have up to 8 sockets. Several bytes
// of RAM are used for each socket. Reducing the maximum can save RAM, but
// you are limited to fewer simultaneous connections.
#if defined(RAMEND) && defined(RAMSTART) && ((RAMEND - RAMSTART) <= 2048)
#define MAX_SOCK_NUM 4
#else
#define MAX_SOCK_NUM 8
#endif
#endifBefore #define MAX_SOCK_NUM 4
#define ETHERNET_LARGE_BUFFERS
#include <Ethernet.h>This will also give the larger buffers |
I checked MIDI-OX on my ENC28J60. The behaviour gets a little bit better. When playing the midi file you linked from Wikipedia, packets get dropped rarely, mostly some control commands at the start or stop of playback, but most note commands come through. When playing my sample file with adjecent notes, sometimes fewer packets get dropped, but most of the time there is no much difference. I think chances are low to get better results with the old ENC28J60, so I will get rid of it. The W5500 already received here, but I did not have time until now to check. I will report how the W5500 works here. |
|
FYI: The |
|
highly recommend using https://github.com/lathoub/Ethernet don't seem to work in the shipping library; so modified them directly in my forked version. Not sure if https://github.com/arduino-libraries/Ethernet is still maintained! :-( |
|
After all, I now got the W5500 running :-) It took me several hours to find out why it did not run out of the box: The ethernet library (w5100.cpp) uses the default Arduino pin 10 for SS, but my board (a bare AVR controller with the MightyCore package) has the SS at pin 4. So I needed to define PIN_SPI_SS_ETHERNET_LIB in the specific pins_arduino.h file. Very annoying bug. I also use your modified ethernet library, but just changed #define SPI_ETHERNET_SETTINGS SPISettings(14000000, MSBFIRST, SPI_MODE0) to #define SPI_ETHERNET_SETTINGS SPISettings(20000000, MSBFIRST, SPI_MODE0) to get maximum SPI speed. And finally, AppleMidi runs like a charme without any dropped packages :-) Thanks a lot for your extensive support! |
|
Super to hear!
I learned something new, thanks for sharing that. Pls close this issue when you are ready |
|
This issue is described in the wiki |
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
The text was updated successfully, but these errors were encountered: