instabilities #55
Comments
folkertvanheusden
changed the title
That's when talking to a https://github.com/lathoub/Arduino-AppleMIDI-Library They're generated when the arduino sends data via wifi through rtpmidid. The other direction works fine. |
|
I ran rtpmidid in valgrind. When I pressed ctrl+c at some point, I got: |
|
This is an example of a disappearing service. "ESI MIDIMATE eX-ESI MIDIMATE eX MIDI 1" is a midi-to-usb-interface on my laptop, 192.168.65.156:5004 is the 'AppleMIDI-ESP8266'. Now what I find puzzling is why this is printed: Here the control port and the midi-port are the same port? so without any modifications by me. In lib/rtpclient.cpp, there's and at line 154 you see: Shouldn't that be "::getsockname(midi_socket, (struct sockaddr *)&servaddr, &len);" ? Also some debug output a few lines below is wrong I believe. If you agree (see) I can do a pull-request. I also see something crash at the other end (the arduino, well esp8266) so something might be wrong at the other end as well. Or rtpmidid is sending something invalid? |
Merged
|
update: there is NO difference between ethernet and wifi. It still may be a timing problem, not perse a too long latency (over vpn worked fine for example (aprox. 100ms latency)). From what I saw in the source code, it is avahi telling rtpmidi that the other end is gone. How does it handle packet loss? At home I have about 2.1% packetloss (wifi or ethernet(-over-power), both not 100% reliable - strangely enough 0% packet loss over vpn). |
|
Also strange: sometimes connecting some source to a local fluidsynth works fine ONLY if I also connect it to an other service. See screendumps to see what I mean. This gives silence:
This works fine:
Note that connecting the arduino source to a windows pc (from windows) works fine as well. |
|
I also detected the other day something similar, but thought it was related to disconnection. My case was connecting to two alsa ports, and disconnecting one of them. Then no data is sent until another port is connected. Do you think that could be your case as well? |
On VPN quite probably the VPN (wireguard) itself is doing some packet resend. Is the VPN directly to the rtpmidid computer? There is no rtpmidi resend support, for that packet loss, whats needed is the journaling support, which is not finished yet. Are you just using a LAN for rtpmidi? or souring though internet or something? 2.1% packet loss is a lot for a LAN IMHO. For me I have 0% (or not quite sure how to check it, 0 packets drops at ifconfig) |
Yes. And also that it did not start to work before I connect two. |
I use tinc; its endpoint is on a virtual machine. Other virtual machines (on the same server) run rtpmidi, usually with my 'metronoom' test-program.
Well it depends. I tested it again and this time I've got 0% packet loss on wifi. The ethernet is over power in my living room, and that's somewhat comparable to ethernet over radio (wifi) and thus prone to packet loss. |
Oh and note: in this example, 'neo' and 'arduino' are directly on the same switch (no vpn, wifi or eop in between). |
|
Please check this logging: it appears that suddenly rtpmidid decides there's a timeout and disconnects. |
|
I did a quick rtpmidi implementation to debug the problems. Now especially at the beginning but also during the session I often receive 'ICMP Destination unreachable' messages. I think that's a bit strange as rtpmidid is supposed to always be listening on those 2 ports? Network trace: rtpmidi.pcap.zip |
|
Its strange that it happens only on port 5004, but it was properly used before.. On a moment I thouhg t it it could be caused byt the network packet losses you were experiencing, but the ICMP message is sent by the proper OS.. so it should be ok. Maybe some timing when creating the ports? I think we create one first and then the second after the first is connected. Maybe we can create them both at the same time so its ready for later? But it does not make sense as some packets seem to arrive and others not. anyway t seems to be totally related to the journaling, as its on feedback packets that it gets the errors. I would try to create some test program that is able to reproduce the problem reliablily, so we can fix it completely. |
|
I'll put my test-program on-line: https://github.com/folkertvanheusden/frtpm It hardcoded listens on port 5004/5005 and creates an ALSA port on which everything is outputted. should work. The two problems I see with that program:
|
|
In void rtppeer::parse_midi(io_bytes_reader &buffer) there's this code: Shouldn't you mask off the 7th bit? Because that contains 'M', indicating if there's MIDI data and that can be set as well I believe: (from docs/RFC6295_notes.md). From 'RFC 6295': |
|
I have a 'DOREMiDi' which is a converter between midi and rtpmidi/apple-midi. 192.168.65.184 is the IP address of the doremidi appliance. Also when it works then that is only for a bit of time: The windows system which is also listening to it, still plays its notes. So mdns_rtpmidi.cpp should not disconnect (imho) while notes still come in. |
|
The arduino AND the DOREMiDi (according to tcpdump) just don't respond to the invitation request. Requests look sane (also according to wireshark). So we have two cases:
|
|
Sometimes when rtpmidid decides to remove an rtp-midi-source, it goes into a loop doing only this: This is a 100% CPU loop which takes a systemlogger with it (also uses 100% CPU) logging this: #73 fixes it in that invalid fds are removed from the poller set but it should be investigated why it was closed and not removed in the first place I guess. |
Looks as if thread A removes something while B is still referring to it. |
|
When connected to a Apple MacBook (both directly on same networkswitch, no wifi or anything), things (like my metronoom-program) sometimes crash (in the librtpmidid library). In the network-trace most of the note-on/off are "malformed" according to wireshark. e.g.: and: |
|
I don't really know if finally fixed in latest version, as I dont have access to DOREMIDI. If still broken, please open a new issue. Thanks for the report and all the information. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I notice that quite often connections "go away". I'm trying to figure this out.
For this, I collect the odd things I notice (errors, etc.).
The text was updated successfully, but these errors were encountered: