rtpmidid rasberrypi to OSX, import not working but export is. #24
Comments
|
Here's the output from running rtpmidid from the command line. I first connect a midi receiver and test it (no data received on RPi) and then disconnect that, connect a midi transmitter and test it (no data received on Mac) and then disconnect that. The only error I see is the control socket not being setup under /var/run/rtpmidid, because I'm not running rtpmidid inside of systemd. Then I connected using the GUI on the mac and repeated the tests. This time data was recieved on both ends. The most obvious difference is that the Latency message repeats at regular intervals. Is there some kind of "keep alive" signal not being sent in the first case? |
|
Hi, thanks for the report. I think you are on the spot on missing latency keep alive (I'm having that exact issue on the windows rtpmidi). But it should at least send messages for some seconds. Actually I'm not sure if I'm having also the same problem of the initial report of remote can connect, but local cant. I will try to work on it a bit and keep you informed. BTW: check https://github.com/davidmoreno/aseqrc which I think is for the same case you want but no need for scripts. Thanks, |
|
I worked a bit on my problem, but now I'm no so sure they are connected. Anyway I changed some paths and added some more debug info. Do you mind trying it again? Also if you have any other device with rtpmidi that works as expected in mac, can you send me the tcpdump? So I can see the differences. Maybe we do something wrong. You can get them with: tcpdump -s 65536 -w dump '(port 5004) or (port 5005)' -i eth0(tested on linux, should be the same) |
|
Still not working. Getting more latency messages, but their irregular and both server and client messages come in pairs. I can run an "rtpmidi" session between two macs if that's what you mean. That should work correctly. Do you want the tcpdump on the server, client or both? |
|
OK, I managed to get a windows virtual machine running rtpMIDI to connect to my Mac. I captured tcpdump's with the mac as both a client and a server. Both worked. The test was: The files are attached |
|
I noticed that rtpMIDI on Windows had a diagnostic output option. I set it on Verbose and connected and disconnected the Mac net1 MIDI port (using the Windows rtpMIDI GUI). Here is the output from that: |
|
From you dumps I see there is a ck handshake: send 6 ck feedback requests 1.5s seconds apart, and then send every 10 seconds. I changed the code to do the same. Let me know if it works. |
|
It does now work, but only on the first connection after the daemon is started. If you disconnect and then reconnect to the net1 midi port no data will flow. Stopping the This usable as is, but I can disconnect and reconnect from the Mac and have the data flow resume. So something is still not right. Let me know if you want any other data I can provide. Here's the output from the daemon process: |
|
I'm checking against windows rtpmidi and I can connect, disconnect, reconnect... no problem. From what I understand you do something like. on the linux side: Where Correct me if I'm (hopefully) wrong. Anyway, again, network dumps will be very useful. I just did a rule on the Makefile: |
|
I have been using command line utilties caled I have also tried connecting to the I assume that the |
|
Here is a run with your latest commit. Same test procedure as in my comment above. The out put from the daemon is below and the dump from your |
|
Tried the same exact test with rtpmidi on Windows instead of the Mac. As you found, it does work after a restart, so something specific to the Mac is the problem. Here are the same data dumps as above, but in the case of a successful test with Windows rtpmidi: |
|
Also tested it connecting from rtpmidi on Windows to the Mac. It does work after a disconnect and reconnect. So something specific to rtpmidid and how it interacts with the Mac Network Midi implementation. |
|
I would need the dump of the windows to mac interaction, to check whats different. The only thing I can think of is that rtpmidid is very liberal on which ports, and communication ids to use. Maybe it should be more strict and always use the same.... But with a win -> mac I will know better. If you restart rtpmidid, does it start working again? (it should be the same... if it does there might be some tip there). |
|
Yes, restarting rtpmidid does start it working again, but only for the first connection. It will still fail if I disconnect and reconnect. I'll do a data capture using the Windows to Mac setup later today. |
|
If you dont mind, can run it through valgrind? Maybe there is some mem problem somewhere? (make valgrind). |
|
There is a |
|
Hi, I think I just fixed this issue, can you check? It is fixed at commit 250162c. I could get a handle on an iPad and try to reproduce and found a problem with the iPad, which I think it is the same you were The problem was that when the other end disconnects I was assuming the other end do not want So now instead of forgetting about the other party, I disconnect all alsa connections (to signal the error) and reset the peer Can you check if it works now? If it does, I will close this issue, and quite probably release a new release with Mac OS and iPad support. |
|
Hey, Thanks for keeping working on this. The power supply for my testbed RPi died, so I haven’t been testing anything. I can swap it out in a couple days and test your new commit. I’ll let you know as soon as I do. Hopefully by Tuesday of this week.
… On Jul 5, 2020, at 4:01 PM, David Moreno Montero ***@***.***> wrote:
Hi, I think I just fixed this issue, can you check?
It is fixed at commit 250162c <250162c>.
I could get a handle on an iPad and try to reproduce and found a problem with the iPad, which I think it is the same you were
having.
The problem was that when the other end disconnects I was assuming the other end do not want
to talk to us again and forgetting about it. I added the cli command update-mdns that forces mdns reannouncement of all
parties, and the remote end connection reappeared and could be used.
So now instead of forgetting about the other party, I disconnect all alsa connections (to signal the error) and reset the peer
information so that new connection attempts will just create a new connection.
Can you check if it works now?
If it does, I will close this issue, and quite probably release a new release with Mac OS and iPad support.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRNJYW6S7TJJQD3XRMGAFLR2DZ3VANCNFSM4NQMGL7A>.
|
|
I can confirm that it does work now. I can disconnect and reconnect from the Raspberry pi to the Mac repeatedly. It takes about 30 seconds to reconnect, which is a little slower than Mac to Mac connections, but perfectly acceptable. I've included the output from the daemon during a reconnect. The MIDI data starts to flow after the Thanks again, |
|
Thanks! I will close this issue and add the 30 seconds problem as another issue. Quite probably I will do a release this weekend with precompiled .deb packages for raspberry pi. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Trying to connect between an RPi and a mac:
Case 1:
-Set up a network midi session called net1 on the mac using the
Audio MIDI SetupGUI.-Start
rtpmididon the RPi.-> Two ALSA midi ports appear on the RPi with the names
Networkandnet1.-connect a MIDI monitor process to the
net1port on the RPi.-> The GUI on the Mac shows that a new participant has been added named raspberrypi/monitor.
-Try to send MIDI data into the Mac net1 port and watch the RPi monitor port
-> No data is received.
-> Same for the reverse case trying to send MIDI data from the RPi to the Mac
Case 2:
-Set up a network midi session called net1 on the mac using the
Audio MIDI SetupGUI.-Start
rtpmididon the RPi.-> Two ALSA midi ports appears on the RPi with the names
Networkandnet1.-Use the Mac GUI to connect the
raspberrypientry in the "Directory" box-> Now there are 3 ALSA midi ports on the RPI, two of them both named
net1.-Connect a midi monitor process to the SECOND
net1port-Try to send MIDI data into the Mac net1 port and watch the RPi monitor port
-> Data is received on the RPi monitor process.
-> Same for the reverse case trying to send MIDI data from the RPi to the Mac
I can also connect the monitor process to the
Networkport on the RPi, manually connect the new raspberrypi/monitor entry from the GUI "Directory" on the Mac and have it work.So it seems that the export, which requires a manual connection in the Mac GUI works, but the Import, which is more automatic, does not, although the Mac seems to think there is a connection.
I really want to use the Import option so that I can set things up using a script on the RPi without having to use the GUI on the Mac every time.
Am I doing something wrong?
Thanks in advance,
Ted
The text was updated successfully, but these errors were encountered: