search

lathoub / Arduino-AppleMIDI-Library

Send and receive MIDI messages over Ethernet (rtpMIDI or AppleMIDI)
Other
311 stars 66 forks source link

Session freeze #20

Closed MaxLeggieri closed 8 years ago

MaxLeggieri commented 8 years ago

Hi, i'm on a macbook with osx 10.10.5 and i've installed the AppleMIDI library, after some setup i can run it fine, also the latency is good but, everytime, after 10 minutes the session freeze, i'm not disconnected from the session but no more notes are going out. After that is very hard to reconnect a session but when its done again, after 10 min, it freeze again...

After the freeze i still can read messages on the serial monitor, perfectly as when it was playing notes.

I'm working with a nodemcu 1.0 board.

Any help? Thanks Max

lathoub commented 8 years ago

Hi Max,

I tried to a Mac (10.11.3) with MIDIPipe and MIDI Network Setup. MIDIPipe is running without an issue and i can send and receive notes, even after 10 or more minutes.

I did however find that when connecting multiple AppleMIDI sessions connecting to the Arduino, that the sessions runs slow and ultimately freezes (I connected from both the Mac and the PC to the Arduino). At first glance, this looks like an Arduino UDP issue (?) and I immediately issued a fix, setting the MAX_SESSION constant to 1.

Can you test to see if that resolves the issue? Did you have multiple sessions going on? Attempting a second connection should receive a rejected error.

Thanks for reporting an issue lathoub

MaxLeggieri commented 8 years ago

Thanks lathoub, My setup will be 6/8 esp connected to the macbook, for now my tests are only with one esp and the macbook.

Will try and let you know in few minutes.

Thanks Max

MaxLeggieri commented 8 years ago

It seems now it freezes after a longer time, when the connection is lost reconnection works well and fast too.

I trigger this during button detection

if(!isConnected) { IPAddress remote(192, 168, 1, 102); AppleMIDI.invite(remote); }

I'll try to log some more data for clues about the freeze, not sure if is the macbook or the esp to cause it...

Thanks Max

MaxLeggieri commented 8 years ago

Anyway, replying your first question, every esp runs as a single invite to the macbook host. With 2 devices it works well too.

On the macbook the partecipants are only one, even if multiple devices, thats nice for now.

lathoub commented 8 years ago

Multiple issues with ES8266 were reported in the past (I tried to run it on a ESP8266 as well, and got reboots) I suspect a compiler issue, but could be the code as well - not sure.

MaxLeggieri commented 8 years ago

Actually no reboots, no compilation errors, everything seems to run smooth. At some point even if the session is still active and still connected on the macbook and the esp the midi data stops to flow. Thats strange...

MaxLeggieri commented 8 years ago

One doubt is on this log lines about the sync:

log

Can you figure out why on the macbook the session is on 5004 and the sync messages sent by the ESP are on port 5005?

I'm explicit inviting with invite(remote,5004) any ideas?

MaxLeggieri commented 8 years ago

Sorry, i just saw that port 5005 (Port+1) is used for the sync.

Now my last question is... How can i have more than one participants to the macbook session? Actually its a problem cause they're seen like one device so if i send a disconnect it disconnects only one device.

Thanks Max

lathoub commented 8 years ago

Max You connect from the device to your Mac, so make sure that the session name is unique (in the .begincommand).

MaxLeggieri commented 8 years ago

Yes, already did this, i take a part of the mac address as a string with a prefix in front like "ESPC5D6"

MaxLeggieri commented 8 years ago

Seems the rtp dissector has some problems

_contentDissector.addPacketDissector(&PacketRtpMidi::dissect_rtp_midi); // Add parser

And the verbose log:

Protocol buffer contains 45 bytes. Content: FF FF 4F 4B 0 0 0 2 12 34 50 1 27 D8 8 D4 4D 61 63 42 6F 6F 6B 20 50 72 6F 20 64 69 20 4D 61 73 73 69 6D 69 6C 69 61 6E 6F 20 0 dissect_rtp_midi 5005, packetSize is 45 dissect_rtp current: 0 unsupported version 3 Unprocessed packet (No valid rtp midi content). dissect_apple_midi 5005, packetSize is 45 Source: 0 Purging left 45 bytes

MaxLeggieri commented 8 years ago

I've seen in other old issue about this problem, don't know if it can be a cause of something.

The problem remains, got no clues from the log and the code... it seems after few minutes (2/3) the ESP continue to log data as it is working correctly but no midi data received on the macbook.

Only after a reset i can reconnect.

Don't know where to look now...

Hackmancoltaire commented 8 years ago

Here's a simple test case that I was able to verify on my Mac with 10.11.4. Using the NoteOnOff sketch after a full reset, it only lasts about 4 minutes before notes stop arriving. Using the most recent commit as of this comment. There has to be some bit of memory leaking, but I can't find it…yet.

Hackmancoltaire commented 8 years ago

Discovered a few issues that I'll be submitting fixes for in a pull request In a couple days. The clock is slightly busted and time stamping of notes was nonexistent. Causing all notes to go out with a time stamp of 0. The clock issue also had implications on the session synchronization. Also found a couple things that weren't to spec with the RFC.

MaxLeggieri commented 8 years ago

Great!

lathoub commented 8 years ago

Yes +1, super!

Hackmancoltaire commented 8 years ago

Submitted Pull Request - https://github.com/lathoub/Arduino-AppleMidi-Library/pull/22

Hackmancoltaire commented 8 years ago

After some extended testing I'm seeing some sync problems, but it stays connected. Soooo, sorta fixed.

MaxLeggieri commented 8 years ago

Great work Ramon! I'll let you know as soon I'll try it.

Thanks

Hackmancoltaire commented 8 years ago

On the ESP8266 issues, I discovered this evening when trying to configure my own Sparkfun Thing board that the UDP_TX_PACKET_MAX_SIZE of 8192 (from the ESP library code) was causing a crash when the Midi framework was trying to allocate memory for it. Manually lowering it in the framework to my proposed 768 seemed to fix the problem immediately. While there seems to be plenty of memory available on the ESP it seems like the high number caused the allocation to stray into other memory and so I was getting crashes all over in very inconsistent ways.

MaxLeggieri commented 8 years ago

Hi Ramon, I did i little test with your modifications and the connection seems more stable. Anyway, when i reset the esp module it reconnects on the fly, udp packets are running on the network but it takes 3-5 minutes to hear again midi on my DAW. I'll take a look on the packets to find out something.

Thanks Max

Hackmancoltaire commented 8 years ago

Unless you're doing an invite in your code you might need to manually restart the session. The session initiatior is responsible for session synchronization. It still needs more testing I'm guessing. I was seeing some sync problems, but it seems after time it resyncs. Part of the problem is each implementation is different, as I'm discovering. Apple's doesn't seem to be 100% complaint with the RFC.

MaxLeggieri commented 8 years ago

Yes, you're right about Apple. My path is to invite the macbook from the esp, when i unplug/replug power from the esp i did again an invite to the laptop but, as i wrote, it takes many time to hear midi on the DAW while rtp packets seems to flow without problems.

Hackmancoltaire commented 8 years ago

The library is now timestamping notes according to its internal clock, and the clock rate. The Mac might be seeing these and because of their timestamp it's queuing them for the future. I was seeing similar behavior over time. The session initiator is supposed to (I think) adjust its clock or add a "delta time" for certain future messages to maintain sync. But testing this has been time consuming (no pun intended) and difficult. Since you're on the ESP I'm assuming this is all happening wirelessly. If you're having any network slowdowns this might also effect the sync.

Hackmancoltaire commented 8 years ago

Looking at WinRTP it looks like they hard-code the delta time of sent commands to 0. We can do that and see if the makes a difference. I'll try to get to that this week.

MaxLeggieri commented 8 years ago

Cool, Thanks Ramon!

Max

Hackmancoltaire commented 8 years ago

I did some more digging and found that timestamps indeed should be 0 if you want the notes to play "now" but I had to dig into the Apple CoreMidi documentation to find it. So I commented those back out and did some more cleanup in my forked branch. I tested it for 30 minutes in my environment and had no problems. Your mileage may vary.

Hackmancoltaire commented 8 years ago

I'm also using this on the ESP and it works great! :D Here are some videos of what I'm using this framework for. https://www.icloud.com/sharedalbum/#B025nhQSTli2IM

lathoub commented 8 years ago

Great work Ramon! - i tested your forked branch on an Arduino and ESP-12 (Adafruit Huzzah). Will you update the pull request with your latest modifications?

Again, thanks for the great work! (and loved your videos, you seem to be a very create man)

Hackmancoltaire commented 8 years ago

Thanks. :D I think the pull request gets updated since it's a pull from my master branch to this master branch. So I think it should work without a problem.

lathoub commented 8 years ago

Without objection, I'm closing this issue

MaxLeggieri commented 8 years ago

No problem, it seems the sessions are not freezing anymore. It will be more difficult to understand well how OSX manages sessions but for now its ok! Great work ;)

stelopin2 commented 8 months ago

I'm also using this on the ESP and it works great! :D Here are some videos of what I'm using this framework for. https://www.icloud.com/sharedalbum/#B025nhQSTli2IM

Whow, that’s amazing. It was fun to see all those photos and videos of the progress you have done and how the people like it. Thank you for sharing this 😄