davidmoreno / rtpmidid Goto Github PK
View Code? Open in Web Editor NEWRTP MIDI (AppleMIDI) daemon for Linux
License: Other
rtpmidid's People
Contributors
Stargazers
Watchers
Forkers
agraef thetechnobear kant dewiweb re-vax videomem stagesoft lathoub dtynski arteme georgeharker aavu my5t3ry electrautistic mcginty folkertvanheusden whoman321 thekikgen dangowrt dvinc abrahamwisman puck sadguitarius johannthorir polygon dsokoloski brettles srki-pravi-frki jtagcat plan44 momomentum kamilica9696rtpmidid's Issues
Error creating server at port 0
I cant figure out whats going on here. Im trying to run it using PatchboxOS to no luck. Any ideas? Ive tried the var trick in CONTROL.md and all the cli options it seems.
`[2021-07-08T07:06:01Z] [main.cpp:58] Real Time Protocol Music Instrument Digital Interface Daemon - 20.04.5
[2021-07-08T07:06:01Z] [main.cpp:59] (C) 2019 David Moreno Montero [email protected]
[2021-07-08T07:06:01Z] [mdns_rtpmidi.cpp:89] watch_new 5 1
[2021-07-08T07:06:01Z] [rtpserver.cpp:65] Try listen at :::5004
[2021-07-08T07:06:01Z] [rtpserver.cpp:110] Error creating server at port 0: Can not open rtpmidi control socket. Address already in use.
[2021-07-08T07:06:01Z] [main.cpp:71] Can't remove fd 6 from poller: Bad file descriptor (9)`
Handle RTP Midi headers with journals.
I'm trying to connect my ipad's midi output to my linux system, so I compiled https://github.com/petegoodliffe/PGMidi because it seemed like the best place to start. It does send the signals (I would presume it's sending note on followed by note off, but I can't say as it's in hex) over the network to rtpmidid, but I'm pretty sure it stops there as rtpmidid prints out [2021-05-02T23:49:30Z] [rtppeer.cpp:402] This RTP MIDI header has journal. Not implemented yet. Ignoring.. So I'm curious what it would take to support them? Difficulty level?
Midi bytes (hex) sent look like [90, 2c, 7f] pause followed by [80,2c,00].
Multiple MIDI commands in one RTP-MIDI frame
Hi,
working on a small MIDI project (https://gitlab.com/ridgy/rtpmidibando), I intended to use rtpmidid on the sythesizer side. There I got some problem with RTP-MIDI command sections consisting of a list of commands (more than one, mixed note and control commands).
Regarding RFC 6295, I tried to change your source to confirm with chapter 3 (MIDI command section). Modifyig rtpmidid.cpp and rtppeer.cpp did solve the problem.
These are the modifications (some are only comments for me to understand the code):
diff --git a/src/rtpmidid.cpp b/src/rtpmidid.cpp
index 0da891f..88ef7a8 100644
--- a/src/rtpmidid.cpp
+++ b/src/rtpmidid.cpp
@@ -392,6 +392,9 @@ void rtpmidid_t::recv_rtpmidi_event(int port, parse_buffer_t &midi_data){
snd_seq_ev_set_subs(&ev);
snd_seq_ev_set_direct(&ev);
snd_seq_event_output_direct(seq.seq, &ev);
+ // There is one delta time byte following, if there are multiple commands in one frame.
+ // We ignore this
+ if (midi_data.position < midi_data.end) midi_data.read_uint8();;
}
}
diff --git a/src/rtppeer.cpp b/src/rtppeer.cpp
index b75756a..4cc009d 100644
--- a/src/rtppeer.cpp
+++ b/src/rtppeer.cpp
@@ -341,30 +341,42 @@ void rtppeer::parse_feedback(parse_buffer_t &buffer){
void rtppeer::parse_midi(parse_buffer_t &buffer){
// auto _headers =
- buffer.read_uint8();
+ buffer.read_uint8(); // Ignore RTP header flags (Byte 0)
auto rtpmidi_id = buffer.read_uint8();
- if (rtpmidi_id != 0x61){
+ if (rtpmidi_id != 0x61){ // next Byte: Paylode type
WARNING("Received packet which is not RTP MIDI. Ignoring.");
return;
}
- remote_seq_nr = buffer.read_uint16();
+ remote_seq_nr = buffer.read_uint16(); // Ignore RTP sequence no.
// TODO In the future we may use a journal.
// auto _remote_timestamp =
- buffer.read_uint32();
- auto remote_ssrc = buffer.read_uint32();
+ buffer.read_uint32(); // Ignore timestamp
+ auto remote_ssrc = buffer.read_uint32();// SSRC
if (remote_ssrc != this->remote_ssrc){
WARNING("Got message for unknown remote SSRC on this port. (from {:04X}, I'm {:04X})", remote_ssrc, this->remote_ssrc);
return;
}
-
+ // RFC 6295 RTP-MIDI _header
+ // The Flags are:
+ // B = has long header
+ // J = has journal
+ // Z = delta time on first MIDI-command present
+ // P = no status byte in original midi command
auto header = buffer.read_uint8();
if ((header & 0x80) != 0){
+ WARNING("This RTP MIDI has long header. Not implemented yet. Ignoring.");
+ return;
+ }
+ if ((header & 0x40) != 0){
WARNING("This RTP MIDI header has journal. Not implemented yet. Ignoring.");
}
- if ((header & 0xB0) != 0){
- WARNING("This RTP MIDI header is too complex. Not implemented yet. Ignoring.");
- return;
+ if ((header & 0x20) != 0){
+ WARNING("This RTP MIDI payload has delta time for the first command. Ignoring.");
+ buffer.read_uint8();
+ }
+ if ((header & 0x10) != 0){
+ WARNING("There was no status byte in original MIDI command. Ignoring.");
}
int16_t length = header & 0x0F;
buffer.check_enought(length);
Maybe you could merge this to the original code.
Kind regards
Richard
Do not depend on systemctl/systemd exclusively for `debian/postinst` and `debian/prerm`
My Debian system is using sysvinit and elogind. This makes the debian packages fail to install due to their reliance on systemctl to start and stop the software.
Selecting previously unselected package rtpmidid.
(Reading database ... 755593 files and directories currently installed.)
Preparing to unpack rtpmidid_20.07_amd64.deb ...
Unpacking rtpmidid (20.07) ...
Setting up rtpmidid (20.07) ...
Adding user rtpmidid to group audio
/var/lib/dpkg/info/rtpmidid.postinst: 28: systemctl: not found
/var/lib/dpkg/info/rtpmidid.postinst: 29: systemctl: not found
dpkg: error processing package rtpmidid (--install):
installed rtpmidid package post-installation script subprocess returned error exit status 127
Errors were encountered while processing:
rtpmidid
I'd suggest checking that it exists and alerting the user that the program cannot be started automatically without systemd, or else maybe some LSB init scripts.
It looks like maybe you were attempting to do this, but at some point your postinst script got messed up. Line 27 of one of them currently reads: if [ -e /usr.
Alternatively you could make systemd | systemctl a hard dependency, but I'd personally rather you didn't since it's unnecessary. I just got it working on my system by rebuilding the debian package with some tweaks to postinst/prerm and a little setgid/setuid trickery (hopefully safe enough) to make rtpmidid run as the rtpmidid user and create a socket file with correct permissions (rtpmidid:audio ownership, I think).
Something like:
type systemctl
if [ $? -ne 0 ]; then
# handle systemctl not found
else
# systemctl commands
fi
Setting up /var/run/rtpmidid and the like would probably be left up to the user on such systems (unless a few more changes are made, anyway), so maybe that would be something to warn people about in the handling section.
Use rtpmidid via wan
Hi.
I would like to use Rtpmidid in the following configuration, but I am not very familiar with the command settings.
We have confirmed that the device is recognized by both RtpMidi and the server.
How would a server set up with the "Rtpmidid" command behave?
Poller time queue backwards
Review poller timer queue. As per #34
The auto retry code wasn't working because (I think) the poller time queue sort order was backwards.
Daemon not opening any ports
I installed rtpmidid and tried to get it to communicate with a Windows VM, but neither machine was able to detect the other.
I looked at the network traffic in Wireshark and while the Windows machine was responding to tcp connections on 5004, the host machine (running Fedora 35) responded to connections on 5004 with "Destination unreachable".
So it turns out that rtpmidid isn't listening on any ports. When I launched rtpmidid I got this output:
[2021-11-26T18:46:06Z] [main.cpp:54] Real Time Protocol Music Instrument Digital Interface Daemon - 21.11
[2021-11-26T18:46:06Z] [main.cpp:56] (C) 2019-2021 David Moreno Montero <[email protected]>
[2021-11-26T18:46:06Z] [mdns_rtpmidi.cpp:88] watch_new 5 1
[2021-11-26T18:46:06Z] [rtpserver.cpp:67] Try listen at :::5004
[2021-11-26T18:46:06Z] [rtpserver.cpp:94] Control port at :::5004
[2021-11-26T18:46:06Z] [rtpserver.cpp:134] Listening RTP MIDI connections at 0.0.0.0:5004, with name: 'the-machine'
[2021-11-26T18:46:06Z] [control_socket.cpp:89] Control socket ready at /var/run/rtpmidid/control.sock
[2021-11-26T18:46:06Z] [mdns_rtpmidi.cpp:303] (Browser) CACHE_EXHAUSTED
[2021-11-26T18:46:06Z] [mdns_rtpmidi.cpp:303] (Browser) ALL_FOR_NOW
[2021-11-26T18:46:07Z] [mdns_rtpmidi.cpp:57] Service '/Client34/EntryGroup1' successfully established
[2021-11-26T18:46:07Z] [mdns_rtpmidi.cpp:283] (Browser) NEW: service 'the-machine' of type '_apple-midi._udp' in domain 'local'
[2021-11-26T18:46:07Z] [mdns_rtpmidi.cpp:283] (Browser) NEW: service 'the-machine' of type '_apple-midi._udp' in domain 'local'
[2021-11-26T18:46:07Z] [mdns_rtpmidi.cpp:283] (Browser) NEW: service 'the-machine' of type '_apple-midi._udp' in domain 'local'
[2021-11-26T18:46:07Z] [mdns_rtpmidi.cpp:283] (Browser) NEW: service 'the-machine' of type '_apple-midi._udp' in domain 'local'
[2021-11-26T18:46:07Z] [mdns_rtpmidi.cpp:283] (Browser) NEW: service 'the-machine' of type '_apple-midi._udp' in domain 'local'
[2021-11-26T18:46:07Z] [mdns_rtpmidi.cpp:230] Received own announcement
[2021-11-26T18:46:07Z] [mdns_rtpmidi.cpp:230] Received own announcement
[2021-11-26T18:46:07Z] [mdns_rtpmidi.cpp:230] Received own announcement
[2021-11-26T18:46:07Z] [mdns_rtpmidi.cpp:230] Received own announcement
[2021-11-26T18:46:07Z] [mdns_rtpmidi.cpp:230] Received own announcement
Sure enough, I checked ss -tnlp and found that no processes were listening on port 5004.
I also tried launching the program with rtpmidid --host 192.168.122.1 (my host ip address) and didn't have any luck.
Am I missing something about how this program works?
can crash when ::sendto returns -1 (by an exception not caught)
If a network interface goes away, e.g. when a VPN is switched off, and rtpmidid was just about to send something through it, it can crash:
terminate called after throwing an instance of 'rtpmidid::exception'
what(): Could not send all data to metronoom:15115. Sent -1. Network is unreachable
Aborted
That's because lib/rtpserver.cpp and lib/rtpclient.cpp have a sendto method that throws an exception if the ::sendto function called in it returns -1.
For EINTR, see #68
instabilities
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.).
Jul 31 17:56:30 lappiemctopface rtpmidid[135084]: #033[0;34m[2021-07-31T15:56:25Z] [rtpmidid.cpp:275]#033[0m Found client to delete: alsa port 3. Deletes all known addreses.
Jul 31 17:56:30 lappiemctopface rtpmidid[135084]: #033[0;34m[2021-07-31T15:56:25Z] [rtpmidid.cpp:574]#033[0m Removing peer from known peers list. Port 3
Jul 31 17:57:53 lappiemctopface rtpmidid[135084]: #033[0;34m[2021-07-31T15:57:48Z] [rtpclient.cpp:156]#033[0m MIDI PORT at port 39352
Jul 31 17:57:53 lappiemctopface rtpmidid[135084]: #033[0;34m[2021-07-31T15:57:48Z] [rtpclient.cpp:182]#033[0m Connecting control port 39352 to ESP-76E44C.dhcp.nurd.space:123
Jul 31 20:24:43 lappiemctopface rtpmidid[162733]: #033[0;34m[2021-07-31T18:24:27Z] [rtpclient.cpp:156]#033[0m MIDI PORT at port 38608
Jul 31 20:24:43 lappiemctopface rtpmidid[162733]: #033[0;34m[2021-07-31T18:24:27Z] [rtpclient.cpp:182]#033[0m Connecting control port 38608 to 192.168.122.178:5004
Jul 31 20:24:43 lappiemctopface rtpmidid[162733]: #033[0;34m[2021-07-31T18:24:27Z] [rtpclient.cpp:188]#033[0m Connecting midi port 38609 to 192.168.122.178:5005
Jul 31 20:32:34 lappiemctopface rtpmidid[162733]: #033[0;31m[2021-07-31T18:32:34Z] [rtpmidid.cpp:479]#033[0m There is no peer but I received an event! This situation should NEVER happen. File a bug. Port 3
Jul 31 20:32:36 lappiemctopface rtpmidid[162733]: message repeated 6 times: [ #033[0;31m[2021-07-31T18:32:34Z] [rtpmidid.cpp:479]#033[0m There is no peer but I received an event! This situation should NEVER happen. File a bug. Port 3]
Jul 31 20:32:36 lappiemctopface rtpmidid[162733]: #033[0;31m[2021-07-31T18:32:35Z] [rtpmidid.cpp:479]#033[0m There is no peer but I received an event! This situation should NEVER happen. File a bug. Port 3
Jul 31 20:32:36 lappiemctopface rtpmidid[162733]: message repeated 10 times: [ #033[0;31m[2021-07-31T18:32:35Z] [rtpmidid.cpp:479]#033[0m There is no peer but I received an event! This situation should NEVER happen. File a bug. Port 3]
Jul 31 20:32:36 lappiemctopface rtpmidid[162733]: #033[0;31m[2021-07-31T18:32:36Z] [rtpmidid.cpp:479]#033[0m There is no peer but I received an event! This situation should NEVER happen. File a bug. Port 3
Jul 31 20:32:36 lappiemctopface rtpmidid[162733]: message repeated 13 times: [ #033[0;31m[2021-07-31T18:32:36Z] [rtpmidid.cpp:479]#033[0m There is no peer but I received an event! This situation should NEVER happen. File a bug. Port 3]
avahi-mdns branch : connection issues/oddities
so I can get this branch to working, but Im seeing the oddities....
(perhaps user errors?)
patch@patchbox:~/projects/rtpmidid/build $ src/rtpmidid
[2019-11-21T15:35:35Z] [main.cpp:46] Real Time Protocol Music Instrument Digital Interface Daemon - alpha 19.05
[2019-11-21T15:35:35Z] [main.cpp:47] (C) 2019 David Moreno Montero <[email protected]>
[2019-11-21T15:35:35Z] [mdns_rtpmidi.cpp:85] watch_new 5 1
[2019-11-21T15:35:35Z] [rtpserver.cpp:84] Listening RTP MIDI connections at 0.0.0.0:5004, with name: 'patchbox'
[2019-11-21T15:35:35Z] [mdns_rtpmidi.cpp:276] (Browser) NEW: service 'bear' of type '_apple-midi._udp' in domain 'local'
[2019-11-21T15:35:35Z] [mdns_rtpmidi.cpp:290] (Browser) CACHE_EXHAUSTED
[2019-11-21T15:35:35Z] [mdns_rtpmidi.cpp:290] (Browser) ALL_FOR_NOW
[2019-11-21T15:35:36Z] [mdns_rtpmidi.cpp:229] Service 'bear' of type '_apple-midi._udp' in domain 'local'
[2019-11-21T15:35:36Z] [mdns_rtpmidi.cpp:248] bear.local:5004 (192.168.1.94)
TXT=
cookie is 0
is_local: false
our_own: false
wide_area: false
multicast: true
cached: true
[2019-11-21T15:35:36Z] [rtpmidid.cpp:193] New alsa port: 1, connects to 192.168.1.94:5004 (bear)
[2019-11-21T15:35:36Z] [mdns_rtpmidi.cpp:58] Service '/Client15/EntryGroup1' successfully established
[2019-11-21T15:35:36Z] [mdns_rtpmidi.cpp:276] (Browser) NEW: service 'patchbox' of type '_apple-midi._udp' in domain 'local'
[2019-11-21T15:35:36Z] [mdns_rtpmidi.cpp:225] Received own announcement
aconnect shows:
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
client 20: 'pisound' [type=kernel,card=1]
0 'pisound MIDI PS-3TG77SW'
client 128: 'rtpmidi patchbox' [type=user,pid=3779]
0 'Network '
1 'mymac '
client 129: 'MEC MIDI OUTPUT' [type=user,pid=3605]
0 'MIDI OUT '
````
so we already appear to have 2 available sessions (0,1)
but if I connect to 0 with aconnect it will crash, and 0 appears to do nothing.
on the mac I see no connection. (so its not auto connected)
seems a few issues in this area ... but not sure what to expect, so probably need to give into these later as separate issues?!
------
ok, on the mac, I see 'patchbox' (my rPI) in directory, but it will not connect to it.
( has a habit of hanging core midi as well :( )
--------
If I manually created an entry on the mac, using IP:5004, then I am able to successful connect to it (it takes a around 5-10secs to connect?)
this create a new alsa session (called 3 'mymac ')
which I can connect to with connect, and this then receives midi and works
yay! success
one small oddity, usually the mac will report latency here, but its not doing this with rtpmidid.
ok, then when I close it, I get
````
[2019-11-21T15:46:14Z] [rtpserver.cpp:172] Unknown peer, and not connect on control. Ignoring. Control port.
FF FF 42 59 00 00 00 02 00 00 00 00 00 47 97 76
..BY .... .... .G.v
````
so definitely its looking pretty good, just a few oddities
however, Im not quite sure what state the avahi-mdns is in, perhaps when merged to master some might be resolved?
test_rtpserver failed
rtpmidid/cmake-build-debug/tests/test_rtpserver
[2020-03-09T19:09:52Z] [test_case.hpp:64]
[2020-03-09T19:09:52Z] [test_case.hpp:65] Test (1/1) test_several_connect_to_server Run
[2020-03-09T19:09:52Z] [test_case.hpp:73] basic_string::_M_construct null not valid
[2020-03-09T19:09:52Z] [test_case.hpp:85] 1 Errors
rtpmidid creates >10GB of sysloglog entries in one minute
I just bought a new device - an iConnectivity mioXM, which also hat rtpmidi capabilities.
So I just wanted to check how it behaves when simply plugged in to my Linux machine (for proper setup it requires a Mac or Windows, maybe also drivers). And things looked good, there where midi ports and stuff, on my mac I saw rtpm,idi stuff from the interface.
But a minute later I got informed that my disk is about to run full, and it turned out my syslog was bloated up to 11GB...
I found huge amounts of lines like this:
Sep 8 19:17:52 henning-ThinkPad-X1-Extreme-2nd rtpmidid[1765]: #033[0;31m[2021-09-08T17:17:52Z] [poller.cpp:200]#033[0m Catched exception at poller: Error reading from rtpp
eer mioXM C09-10:5022
In this second alone 241099 times - alltogether I can grep "poller.cpp" 63521662 in the file.
I assume, but didn't verify in detail if they are all the same...
I haven't yet setup any midi routing, so a loop or something is unlikely, but I can and will check again.
But even with a loop I am not sure if it's useful to log anything multiple hundred k times a second.
The rtpmidid version I am using is a self-built deb from commit 8ed604f
Let me know if there is any more information I can provide.
Missing rtpmidid_20.07_amd64.deb in 20.07 releases
Just for the record, if someone prefers to use the debian binaries..
leaks filedescriptors
[2021-08-02T14:12:15Z] [aseq.cpp:128] New ALSA connection from port Midi Through-Midi Through Port-0 (14:0)
[2021-08-02T14:12:15Z] [rtpmidid.cpp:200] Connected to ALSA port 14:0. Create network server for this alsa data.
[2021-08-02T14:12:15Z] [rtpserver.cpp:65] Try listen at :::0
[2021-08-02T14:12:15Z] [rtpserver.cpp:91] Control port at :::51634
[2021-08-02T14:12:15Z] [rtpserver.cpp:110] Error creating server at port 51634: Can not open MIDI socket. Out of sockets?
[2021-08-02T14:12:15Z] [poller.cpp:200] Catched exception at poller: Can't remove fd -1 from poller: Bad file descriptor (9)
[2021-08-02T14:12:16Z] [aseq.cpp:136] Disconnected
Compile errors
Unsure if it's just my installed version of C++ or what, but I get an error when running make:
rtpmidid-master/src/control_socket.cpp: In member function ‘void rtpmidid::control_socket_t::data_ready(int)’: rtpmidid-master/src/control_socket.cpp:97:11: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Werror=sign-compare] 97 | if (l >= sizeof(buf) - 1){ | ~~^~~~~~~~~~~~~~~~~~ cc1plus: all warnings being treated as errors
I'm on Solus 4.1. G++ 9.2.0. Docs say it should adhere to C++17 when passed the compiler flag, which you do have as -std=c++17.
Any ideas?
Please move mdns_rtpmidi to the library
This is very useful code imho that is related to rtpmidi and thus could be placed in the library.
Auto reconnect needs some things reset before retrying
Auto reconnect needs some things reset before retrying - ports need closing, née initiator ids need generating and some callbacks need disconnecting (mostly the connected one or it would register multiple and get them several times).
See #34
please document librtpmidi
Hi,
Please add some basic documentation for librtpmidi.
E.g. creating a service that serves music or something.
Install issue "`GLIBCXX_3.4.26' not found" (with possible solution)
From a fully updated Ubuntu 18.04, I got the error shown when running rtpmidid installed from rtpmidid_21.11.2.g0edef_amd64.deb and corresponding lib packages.
Based on Google searches, I:
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt update
sudo apt upgrade
and that pulled in a newer version of libstdc++.so.6 and the software runs.
documentation/process improvements
some ideas of how to move forward...
a) tagging/labels - in github
would be useful to be able to tag issues as bug/missing/features , and perhaps 'priority'
so we can get a feel for whats important, but still list things so they are not forgotten'
you can do this nicely with GitHub, by using 'setup issue templates',
when you add these, you can edit them, and automatically assign labels.
e.g. create BUG issue template , edit and BUG label, (repeat for Feature Request)
now users when they do new issue, will see the option to raise a bur or feature request,
and its labelled correctly without you having to do the assignment (unless thats something you'd prefer.
b) tagging in code
use //TODO , and //FIXME in code?
I find useful for code base when its still being developed, so from source code you know where (inevitable) shortcuts are taken during early stages ... also useful for documenting things that are a 'quick' implementation and might be subject to change later
c) debug/logging output
is there a warning level?
why im thinking of the above?
example:
Message Type 48 not implemented (active sense)
this gets repeated in logs... as debug
i think it would be good if this was instead a WARNING, and only printed the first time its encountered. (it shouldn't be debug, since when 'released' you'll still want to know about missing messages type - that we may have forgotten)
GitHub - its not really a bug, just a missing feature
code tagging -
it might be we just ignore active sense for now, or parse it but dont sent it out.
then it be nice to add a TODO/FIXME note in code to point this out.
Takes 30 seconds to reconnect to Mac OS
From #24 , reported by @Rippert
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 Latency net1: 1.20 ms (server / 3) messages stop. Again, I don't think this is a bug, just some info for you.
Thanks again,
Ted
[2020-07-09T19:49:19Z] [aseq.cpp:131] Disconnected
[2020-07-09T19:49:24Z] [aseq.cpp:123] New ALSA connection from port receivemidi-net1 (129:0)
[2020-07-09T19:49:24Z] [rtpmidid.cpp:261] Callback on subscribe at rtpmidid: receivemidi-net1
[2020-07-09T19:49:24Z] [rtpclient.cpp:78] Try connect to service at 10.0.1.13:5004
[2020-07-09T19:49:24Z] [rtpclient.cpp:100] Try connect to resolved name: TedsAir.local.nat:5004
[2020-07-09T19:49:24Z] [rtpclient.cpp:119] Connected to resolved name: TedsAir.local.nat:5004
[2020-07-09T19:49:24Z] [rtpclient.cpp:128] Control port, local: 58213, remote at TedsAir.local.nat:5004
[2020-07-09T19:49:24Z] [rtpclient.cpp:157] MIDI PORT at port 58213
[2020-07-09T19:49:24Z] [rtpclient.cpp:183] Connecting control port 58213 to TedsAir.local.nat:5004
[2020-07-09T19:49:24Z] [rtppeer.cpp:154] Got confirmation from net1, initiator_id: 376414137 (true) ssrc: 3344945440, name: net1, port: Control
[2020-07-09T19:49:24Z] [rtpclient.cpp:190] Connecting midi port 58214 to 10.0.1.13:5005
[2020-07-09T19:49:24Z] [rtppeer.cpp:154] Got confirmation from net1, initiator_id: 376414137 (true) ssrc: 3344945440, name: net1, port: MIDI
[2020-07-09T19:49:24Z] [rtppeer.cpp:349] Send CK0 to net1
[2020-07-09T19:49:24Z] [rtppeer.cpp:288] Latency net1: 1.20 ms (client / 2)
[2020-07-09T19:49:34Z] [rtppeer.cpp:349] Send CK0 to net1
[2020-07-09T19:49:34Z] [rtppeer.cpp:288] Latency net1: 125.70 ms (client / 2)
[2020-07-09T19:49:34Z] [rtppeer.cpp:296] Latency net1: 1.20 ms (server / 3)
[2020-07-09T19:49:44Z] [rtppeer.cpp:349] Send CK0 to net1
[2020-07-09T19:49:44Z] [rtppeer.cpp:288] Latency net1: 125.80 ms (client / 2)
[2020-07-09T19:49:44Z] [rtppeer.cpp:296] Latency net1: 1.20 ms (server / 3)
[2020-07-09T19:49:54Z] [rtppeer.cpp:349] Send CK0 to net1
[2020-07-09T19:49:54Z] [rtppeer.cpp:288] Latency net1: 126.00 ms (client / 2)
[2020-07-09T19:50:04Z] [rtppeer.cpp:349] Send CK0 to net1
[2020-07-09T19:50:05Z] [rtppeer.cpp:288] Latency net1: 130.80 ms (client / 2)
[2020-07-09T19:50:15Z] [rtppeer.cpp:349] Send CK0 to net1
[2020-07-09T19:50:15Z] [rtppeer.cpp:288] Latency net1: 129.50 ms (client / 2)
[2020-07-09T19:50:20Z] [rtpmidid.cpp:266] Callback on unsubscribe at rtpmidid
[2020-07-09T19:50:20Z] [rtpmidid.cpp:325] Disconnect signal: 3
[2020-07-09T19:50:20Z] [rtppeer.cpp:50] ~rtppeer 'raspberrypi/receivemidi-net1' (local) <-> 'net1' (remote)
[2020-07-09T19:50:20Z] [aseq.cpp:131] Disconnected
how to handle very long sysex messages
I'm trying to send long sysex dumps through rtpmidid, and it looks like I'm running into the hard cap of 4096 bytes imposed by rtpmidid. I just tried recompiling rtpmidid with the numbers that appear in commit 7dcfed9 set to higher values, but this doesn't work. It sounds like ALSA has some general issues with long MIDI messages. I also see there are some previous conversations about adding segmentation to long midi buffers.
The other option I was wondering about, which may be easier to implement for now, would be the possibility of diverting a message to a virtual raw MIDI port created by the amidi command. Currently this doesn't work because rtpmidid waits for the full message to come in before sending it on to the connected port.
I'd be happy to take a look at this stuff in the code if anyone can help point me in the right direction of where to start looking. Thanks!
Qt conflicts because of variables named "slots"
I needed to use this library in a QT environment, and unfortunately the project doesn't build because of the word slots is reserved. QT is using signal/slots mechanism, and unfortunately it seems like the variables cannot be names "slots". So renaming this to m_slots or slots_ would resolve this issue.
Readme slightly unclear
The readme reads:
To export a local alsa sequencer port, connect it to the "Network" port.
It will create the server, announce the mDNS service so other endpoints know it exist, and accept connections.
I have a Roland piano attached to my raspberry Pi but based on this info, it's unclear to me how to use RTPMIDID with a Windows laptop to communicate with the piano attached to the Pi, for example.
Compile failure on Arch Linux
Arch Linux (kernel 5.12.12)
gcc (GCC) 11.1.0
clang version 12.0.0 (but it looks like it's auto-selecting GCC)
Sorry, I'm far from an expert in debugging C++ build issues, but here are the outputs, and please let me know if anything else can help.
cmake -B build
-- The C compiler identification is GNU 11.1.0
-- The CXX compiler identification is GNU 11.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ju/git/rtpmidid/build
make build
mkdir -p build
cd build && cmake .. -DCMAKE_BUILD_TYPE=Release
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ju/git/rtpmidid/build
cd build && make -j
make[1]: warning: -j0 forced in submake: resetting jobserver mode.
make[1]: Entering directory '/home/ju/git/rtpmidid/build'
make[2]: Entering directory '/home/ju/git/rtpmidid/build'
make[3]: Entering directory '/home/ju/git/rtpmidid/build'
make[3]: Entering directory '/home/ju/git/rtpmidid/build'
Consolidate compiler generated dependencies of target rtpmidid-shared
make[3]: Leaving directory '/home/ju/git/rtpmidid/build'
Consolidate compiler generated dependencies of target rtpmidid-static
make[3]: Leaving directory '/home/ju/git/rtpmidid/build'
[ 20%] Built target rtpmidid-shared
make[3]: Entering directory '/home/ju/git/rtpmidid/build'
make[3]: Entering directory '/home/ju/git/rtpmidid/build'
make[3]: Entering directory '/home/ju/git/rtpmidid/build'
[ 41%] Built target rtpmidid-static
Consolidate compiler generated dependencies of target test_poller
make[3]: Entering directory '/home/ju/git/rtpmidid/build'
make[3]: Leaving directory '/home/ju/git/rtpmidid/build'
Consolidate compiler generated dependencies of target test_rtppeer
Consolidate compiler generated dependencies of target test_rtpserver
make[3]: Leaving directory '/home/ju/git/rtpmidid/build'
make[3]: Leaving directory '/home/ju/git/rtpmidid/build'
[ 51%] Built target test_poller
Consolidate compiler generated dependencies of target rtpmidid-daemon
make[3]: Leaving directory '/home/ju/git/rtpmidid/build'
[ 62%] Built target test_rtpserver
[ 72%] Built target test_rtppeer
make[3]: Entering directory '/home/ju/git/rtpmidid/build'
[ 75%] Building CXX object src/CMakeFiles/rtpmidid-daemon.dir/main.cpp.o
[ 79%] Building CXX object src/CMakeFiles/rtpmidid-daemon.dir/rtpmidid.cpp.o
[ 82%] Building CXX object src/CMakeFiles/rtpmidid-daemon.dir/control_socket.cpp.o
In file included from /home/ju/git/rtpmidid/src/rtpmidid.cpp:23:
/home/ju/git/rtpmidid/src/./rtpmidid.hpp:72:8: error: ‘optional’ in namespace ‘std’ does not name a template type
72 | std::optional<uint8_t> add_rtpmidi_client(const std::string &hostdescription);
| ^~~~~~~~
/home/ju/git/rtpmidid/src/./rtpmidid.hpp:26:1: note: ‘std::optional’ is defined in header ‘<optional>’; did you forget to ‘#include <optional>’?
25 | #include <set>
+++ |+#include <optional>
26 | #include <string>
/home/ju/git/rtpmidid/src/./rtpmidid.hpp:73:8: error: ‘optional’ in namespace ‘std’ does not name a template type
73 | std::optional<uint8_t> add_rtpmidi_client(const std::string &name,
| ^~~~~~~~
/home/ju/git/rtpmidid/src/./rtpmidid.hpp:73:3: note: ‘std::optional’ is defined in header ‘<optional>’; did you forget to ‘#include <optional>’?
73 | std::optional<uint8_t> add_rtpmidi_client(const std::string &name,
| ^~~
In file included from /home/ju/git/rtpmidid/src/main.cpp:26:
/home/ju/git/rtpmidid/src/./rtpmidid.hpp:72:8: error: ‘optional’ in namespace ‘std’ does not name a template type
72 | std::optional<uint8_t> add_rtpmidi_client(const std::string &hostdescription);
| ^~~~~~~~
/home/ju/git/rtpmidid/src/./rtpmidid.hpp:26:1: note: ‘std::optional’ is defined in header ‘<optional>’; did you forget to ‘#include <optional>’?
25 | #include <set>
+++ |+#include <optional>
26 | #include <string>
/home/ju/git/rtpmidid/src/./rtpmidid.hpp:73:8: error: ‘optional’ in namespace ‘std’ does not name a template type
73 | std::optional<uint8_t> add_rtpmidi_client(const std::string &name,
| ^~~~~~~~
/home/ju/git/rtpmidid/src/./rtpmidid.hpp:73:3: note: ‘std::optional’ is defined in header ‘<optional>’; did you forget to ‘#include <optional>’?
73 | std::optional<uint8_t> add_rtpmidi_client(const std::string &name,
| ^~~
/home/ju/git/rtpmidid/src/rtpmidid.cpp: In constructor ‘rtpmidid::rtpmidid_t::rtpmidid_t(rtpmidid::config_t*)’:
/home/ju/git/rtpmidid/src/rtpmidid.cpp:44:16: error: ‘add_rtpmidi_client’ was not declared in this scope; did you mean ‘remove_rtpmidi_client’?
44 | auto res = add_rtpmidi_client(connect_to);
| ^~~~~~~~~~~~~~~~~~
| remove_rtpmidi_client
/home/ju/git/rtpmidid/src/rtpmidid.cpp:45:21: error: ‘nullopt’ is not a member of ‘std’
45 | if (res == std::nullopt) {
| ^~~~~~~
/home/ju/git/rtpmidid/src/rtpmidid.cpp: At global scope:
/home/ju/git/rtpmidid/src/rtpmidid.cpp:51:6: error: ‘optional’ in namespace ‘std’ does not name a template type
51 | std::optional<uint8_t>
| ^~~~~~~~
/home/ju/git/rtpmidid/src/rtpmidid.cpp:29:1: note: ‘std::optional’ is defined in header ‘<optional>’; did you forget to ‘#include <optional>’?
28 | #include <rtpmidid/rtpserver.hpp>
+++ |+#include <optional>
29 |
/home/ju/git/rtpmidid/src/rtpmidid.cpp: In lambda function:
/home/ju/git/rtpmidid/src/rtpmidid.cpp:213:11: error: ‘class rtpmidid::rtpmidid_t’ has no member named ‘add_rtpmidi_client’; did you mean ‘remove_rtpmidi_client’?
213 | this->add_rtpmidi_client(name, address, port);
| ^~~~~~~~~~~~~~~~~~
| remove_rtpmidi_client
/home/ju/git/rtpmidid/src/rtpmidid.cpp: At global scope:
/home/ju/git/rtpmidid/src/rtpmidid.cpp:222:6: error: ‘optional’ in namespace ‘std’ does not name a template type
222 | std::optional<uint8_t>
| ^~~~~~~~
/home/ju/git/rtpmidid/src/rtpmidid.cpp:222:1: note: ‘std::optional’ is defined in header ‘<optional>’; did you forget to ‘#include <optional>’?
222 | std::optional<uint8_t>
| ^~~
make[3]: *** [src/CMakeFiles/rtpmidid-daemon.dir/build.make:118: src/CMakeFiles/rtpmidid-daemon.dir/main.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs....
In file included from /home/ju/git/rtpmidid/src/control_socket.cpp:28:
/home/ju/git/rtpmidid/src/./rtpmidid.hpp:72:8: error: ‘optional’ in namespace ‘std’ does not name a template type
72 | std::optional<uint8_t> add_rtpmidi_client(const std::string &hostdescription);
| ^~~~~~~~
/home/ju/git/rtpmidid/src/./rtpmidid.hpp:26:1: note: ‘std::optional’ is defined in header ‘<optional>’; did you forget to ‘#include <optional>’?
25 | #include <set>
+++ |+#include <optional>
26 | #include <string>
/home/ju/git/rtpmidid/src/./rtpmidid.hpp:73:8: error: ‘optional’ in namespace ‘std’ does not name a template type
73 | std::optional<uint8_t> add_rtpmidi_client(const std::string &name,
| ^~~~~~~~
/home/ju/git/rtpmidid/src/./rtpmidid.hpp:73:3: note: ‘std::optional’ is defined in header ‘<optional>’; did you forget to ‘#include <optional>’?
73 | std::optional<uint8_t> add_rtpmidi_client(const std::string &name,
| ^~~
/home/ju/git/rtpmidid/src/control_socket.cpp: In function ‘json rtpmidid::commands::create(rtpmidid::rtpmidid_t&, const string&, const string&, const string&)’:
/home/ju/git/rtpmidid/src/control_socket.cpp:197:29: error: ‘class rtpmidid::rtpmidid_t’ has no member named ‘add_rtpmidi_client’; did you mean ‘remove_rtpmidi_client’?
197 | auto alsa_port = rtpmidid.add_rtpmidi_client(name, host, port);
| ^~~~~~~~~~~~~~~~~~
| remove_rtpmidi_client
/home/ju/git/rtpmidid/src/control_socket.cpp:201:5: error: could not convert ‘{{"alsa_port", <expression error>}}’ from ‘<brace-enclosed initializer list>’ to ‘json’ {aka ‘nlohmann::basic_json<>’}
201 | };
| ^
| |
| <brace-enclosed initializer list>
make[3]: *** [src/CMakeFiles/rtpmidid-daemon.dir/build.make:146: src/CMakeFiles/rtpmidid-daemon.dir/rtpmidid.cpp.o] Error 1
make[3]: *** [src/CMakeFiles/rtpmidid-daemon.dir/build.make:160: src/CMakeFiles/rtpmidid-daemon.dir/control_socket.cpp.o] Error 1
make[3]: Leaving directory '/home/ju/git/rtpmidid/build'
make[2]: *** [CMakeFiles/Makefile2:192: src/CMakeFiles/rtpmidid-daemon.dir/all] Error 2
make[2]: Leaving directory '/home/ju/git/rtpmidid/build'
make[1]: *** [Makefile:101: all] Error 2
make[1]: Leaving directory '/home/ju/git/rtpmidid/build'
make: *** [Makefile:19: build/bin/rtpmidid] Error 2
suggestion: add OSS support
To make this daemon truly universal it really needs to support more than just ALSA.
For FreeBSD, OSS support would be helpful. Additionally, if you use fluidsynth as your tone generator under FreeBSD or Linux, support for libfluidsynth would be extremely useful.
(I have done a simple ethernet MIDI implementation (using a different protocol) that invokes fluidsynth this way - you can search for the project under my user name if you want to see what I did)
will not connect to iphone rtp session
Options do not work. it will not connect to iphone rtp session. You can not connect to mac or windows devices from terminal using raspberry pi.
Long header in MIDI Command Section
Bandoneon project: Changing pressure direction when having hit some keys simultaneously led to midi list length > 16 bytes (one AllNotesOff, up to sixteen NoteOn, maybe running status). Thus, long headers have to be dealed with. This is a minor possible modification, according to RFC 6295:
diff --git a/src/rtppeer.cpp b/src/rtppeer.cpp
index c4fb49e..5bd3e26 100644
--- a/src/rtppeer.cpp
+++ b/src/rtppeer.cpp
@@ -397,9 +397,10 @@ void rtppeer::parse_midi(parse_buffer_t &buffer) {
// Z = delta time on first MIDI-command present
// P = no status byte in original midi command
auto header = buffer.read_uint8();
+ int16_t length = -1;
if ((header & 0x80) != 0) {
- WARNING("This RTP MIDI has long header. Not implemented yet. Ignoring.");
- return;
+ length = buffer.read_uint8(); // If long header: Next byte is lower 8 bits of length field
+ WARNING("This RTP MIDI has long header. Second byte is {:02X}", length);
}
if ((header & 0x40) != 0) {
WARNING("This RTP MIDI header has journal. Not implemented yet. Ignoring.");
@@ -412,7 +413,8 @@ void rtppeer::parse_midi(parse_buffer_t &buffer) {
if ((header & 0x10) != 0) {
WARNING("There was no status byte in original MIDI command. Ignoring.");
}
- int16_t length = header & 0x0F;
+ if (length < 0) length = header & 0x0F; // Short header: only 4 bit length
+ else length += (header & 0x0F) << 8; // Long header: Most significant 4 bits of length
buffer.check_enough(length);
parse_buffer_t midi_data(buffer.position, length);
In theory the command section length could be 4096 bytes, but your buffer is much smaller. Practically I did not see command section length more than 100 bytes. buffer.check_enough() handles situations with very long midi lists; these are then ignored.
Please check and merge at your decision.
keeps crashing
Jul 30 22:13:40 lappiemctopface systemd[1]: Started rtpmidid.
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;37m[2021-07-30T20:13:40Z] [main.cpp:57]#33[0m Real Time Protocol Music Instrument Digital Interface Daemon - 21.07.1
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;37m[2021-07-30T20:13:40Z] [main.cpp:59]#33[0m (C) 2019-2021 David Moreno Montero [email protected]
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:40Z] [mdns_rtpmidi.cpp:89]#33[0m watch_new 5 1
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:40Z] [rtpserver.cpp:65]#33[0m Try listen at :::5004
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:40Z] [rtpserver.cpp:91]#33[0m Control port at :::5004
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;37m[2021-07-30T20:13:40Z] [rtpserver.cpp:130]#33[0m Listening RTP MIDI connections at 0.0.0.0:5004, with name: 'lappiemctopface'
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;37m[2021-07-30T20:13:40Z] [control_socket.cpp:81]#33[0m Control socket ready at /var/run/rtpmidid/control.sock
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;37m[2021-07-30T20:13:40Z] [aseq.cpp:123]#33[0m New ALSA connection from port FLUID Synth (41134)-Synth input port (41134:0) (128:0)
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:40Z] [rtpmidid.cpp:200]#33[0m Connected to ALSA port 128:0. Create network server for this alsa data.
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:40Z] [rtpserver.cpp:65]#33[0m Try listen at :::0
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:40Z] [rtpserver.cpp:91]#33[0m Control port at :::34764
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;37m[2021-07-30T20:13:40Z] [rtpserver.cpp:130]#33[0m Listening RTP MIDI connections at 0.0.0.0:34764, with name: 'lappiemctopface/FLUID Synth (41134)-Synth input port (41134:0)'
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;37m[2021-07-30T20:13:40Z] [mdns_rtpmidi.cpp:284]#33[0m (Browser) NEW: service 'metronoom' of type '_apple-midi._udp' in domain 'local'
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: message repeated 6 times: [ #33[0;37m[2021-07-30T20:13:40Z] [mdns_rtpmidi.cpp:284]#33[0m (Browser) NEW: service 'metronoom' of type '_apple-midi._udp' in domain 'local']
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;37m[2021-07-30T20:13:40Z] [mdns_rtpmidi.cpp:304]#33[0m (Browser) CACHE_EXHAUSTED
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;37m[2021-07-30T20:13:40Z] [mdns_rtpmidi.cpp:304]#33[0m (Browser) ALL_FOR_NOW
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:40Z] [mdns_rtpmidi.cpp:235]#33[0m Discovered service 'metronoom' of type '_apple-midi._udp' in domain 'local'
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;37m[2021-07-30T20:13:40Z] [rtpmidid.cpp:243]#33[0m New alsa port: 1, connects to host: fe80::c5c:f3ff:fe8a:57f5, port: 0, name: metronoom
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:40Z] [mdns_rtpmidi.cpp:235]#33[0m Discovered service 'metronoom' of type '_apple-midi._udp' in domain 'local'
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: message repeated 5 times: [ #33[0;34m[2021-07-30T20:13:40Z] [mdns_rtpmidi.cpp:235]#33[0m Discovered service 'metronoom' of type '_apple-midi._udp' in domain 'local']
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;37m[2021-07-30T20:13:40Z] [aseq.cpp:123]#33[0m New ALSA connection from port FLUID Synth (41134)-Synth input port (41134:0) (128:0)
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:40Z] [rtpmidid.cpp:249]#33[0m Callback on subscribe at rtpmidid: FLUID Synth (41134)-Synth input port (41134:0)
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:40Z] [rtpclient.cpp:77]#33[0m Try connect to service at fe80::c5c:f3ff:fe8a:57f5:0
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:40Z] [rtpclient.cpp:99]#33[0m Try connect to resolved name: lappiemctopface:0
Jul 30 22:13:40 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:40Z] [rtpclient.cpp:113]#33[0m Error opening control socket, port 0
Jul 30 22:13:41 lappiemctopface rtpmidid[41360]: #33[0;31m[2021-07-30T20:13:40Z] [rtpclient.cpp:161]#33[0m Error creating rtp client: Can not open remote rtpmidi control socket. Address family not supported by protocol
Jul 30 22:13:41 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:40Z] [rtpmidid.cpp:313]#33[0m Disconnect signal: 0
Jul 30 22:13:41 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:41Z] [rtpmidid.cpp:331]#33[0m Try connect next in list. Idx 1/7
Jul 30 22:13:41 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:41Z] [rtpclient.cpp:77]#33[0m Try connect to service at 172.29.0.99:0
Jul 30 22:13:41 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:41Z] [rtpclient.cpp:99]#33[0m Try connect to resolved name: lappiemctopface:0
Jul 30 22:13:41 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:41Z] [rtpclient.cpp:118]#33[0m Connected to resolved name: lappiemctopface:0
Jul 30 22:13:41 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:41Z] [rtpclient.cpp:126]#33[0m Control port, local: 55756, remote at lappiemctopface:0
Jul 30 22:13:41 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:41Z] [rtpclient.cpp:156]#33[0m MIDI PORT at port 55756
Jul 30 22:13:41 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:41Z] [rtpclient.cpp:182]#33[0m Connecting control port 55756 to lappiemctopface:0
Jul 30 22:13:41 lappiemctopface rtpmidid[41360]: #33[0;34m[2021-07-30T20:13:41Z] [rtppeer.cpp:50]#33[0m ~rtppeer 'lappiemctopface/FLUID Synth (41134)-Synth input port (41134:0)' (local) <-> '' (remote)
Jul 30 22:13:41 lappiemctopface rtpmidid[41360]: #33[0;31m[2021-07-30T20:13:41Z] [main.cpp:71]#33[0m Could not send all data to :0. Sent -1. Invalid argument
Jul 30 22:13:41 lappiemctopface systemd[1]: rtpmidid.service: Main process exited, code=exited, status=1/FAILURE
Jul 30 22:13:41 lappiemctopface systemd[1]: rtpmidid.service: Failed with result 'exit-code'.
Jul 30 22:13:41 lappiemctopface systemd[1]: rtpmidid.service: Scheduled restart job, restart counter is at 6.
Jul 30 22:13:41 lappiemctopface systemd[1]: Stopped rtpmidid.
Jul 30 22:13:41 lappiemctopface systemd[1]: rtpmidid.service: Start request repeated too quickly.
Jul 30 22:13:41 lappiemctopface systemd[1]: rtpmidid.service: Failed with result 'exit-code'.
Jul 30 22:13:41 lappiemctopface systemd[1]: Failed to start rtpmidid.
Note that that metronoom just does:
std::string port = "0", name = "metronoom";
rtpmidid::rtpserver am(name, port);
rtpmidid::mdns_rtpmidi mdns_rtpmidi;
...
mdns_rtpmidi.announce_rtpmidi(name, atoi(port.c_str()));
am.connected_event.connect([](std::shared_ptr<::rtpmidid::rtppeer> peer) {
INFO("Remote client connects to local server at port {}. Name: {}", port, peer->remote_name);
});
Consistent creation of ssrc
Ssrc on the source end is important. And needs something repeatable but random. I used a hash on the source name. Which for connections from alsa programs using mido is always the same. But maybe it should be local host name + dest host name hashed. The rfc indicates there's need for collision detection logic. Which I didn't quite grok their example of yet.
See related #34
Build fails on Raspberry Pi
Possibly trivial to fix, but I'm very bad at cmake builds (sorry).
Running Raspbian on Raspberrry Pi 3
uname -a
Linux raspberrypi 5.4.51-v7+ #1333 SMP Mon Aug 10 16:45:19 BST 2020 armv7l GNU/Linux
gcc --version
gcc (Raspbian 8.3.0-6+rpi1) 8.3.0
Fresh clone of github repo, master branch. Also tried building from v20.07 tag with same results:
make build
[...]
[38%] Building CXX object lib/CMakeFiles/rtpmidid-shared.dir/poller.cpp.o
/home/pi/rtpmidid/lib/logger.cpp:20:10: fatal error: fmt/ostream.h: No such file or directory
#include <fmt/ostream.h>
^~~~~~~~~~~~~~~
compilation terminated.
In file included from /home/pi/rtpmidid/lib/rtppeer.cpp:20:
/home/pi/rtpmidid/include/rtpmidid/exceptions.hpp:22:10: fatal error: fmt/format.h: No such file or directory
#include <fmt/format.h>
^~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [lib/CMakeFiles/rtpmidid-shared.dir/build.make:102: lib/CMakeFiles/rtpmidid-shared.dir/logger.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [lib/CMakeFiles/rtpmidid-shared.dir/build.make:63: lib/CMakeFiles/rtpmidid-shared.dir/rtppeer.cpp.o] Error 1
/home/pi/rtpmidid/lib/logger.cpp:20:10: fatal error: fmt/ostream.h: No such file or directory
#include <fmt/ostream.h>
^~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [lib/CMakeFiles/rtpmidid-static.dir/build.make:102: lib/CMakeFiles/rtpmidid-static.dir/logger.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs....
In file included from /home/pi/rtpmidid/lib/rtppeer.cpp:20:
/home/pi/rtpmidid/include/rtpmidid/exceptions.hpp:22:10: fatal error: fmt/format.h: No such file or directory
#include <fmt/format.h>
^~~~~~~~~~~~~~
compilation terminated.
In file included from /home/pi/rtpmidid/lib/poller.cpp:24:
/home/pi/rtpmidid/include/rtpmidid/exceptions.hpp:22:10: fatal error: fmt/format.h: No such file or directory
#include <fmt/format.h>
^~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [lib/CMakeFiles/rtpmidid-static.dir/build.make:63: lib/CMakeFiles/rtpmidid-static.dir/rtppeer.cpp.o] Error 1
In file included from /home/pi/rtpmidid/lib/poller.cpp:24:
/home/pi/rtpmidid/include/rtpmidid/exceptions.hpp:22:10: fatal error: fmt/format.h: No such file or directory
#include <fmt/format.h>
^~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [lib/CMakeFiles/rtpmidid-static.dir/build.make:115: lib/CMakeFiles/rtpmidid-static.dir/poller.cpp.o] Error 1
make[3]: *** [lib/CMakeFiles/rtpmidid-shared.dir/build.make:115: lib/CMakeFiles/rtpmidid-shared.dir/poller.cpp.o] Error 1
In file included from /home/pi/rtpmidid/include/rtpmidid/iobytes.hpp:21,
from /home/pi/rtpmidid/lib/rtpclient.cpp:32:
/home/pi/rtpmidid/include/rtpmidid/./exceptions.hpp:22:10: fatal error: fmt/format.h: No such file or directory
#include <fmt/format.h>
^~~~~~~~~~~~~~
compilation terminated.
In file included from /home/pi/rtpmidid/lib/rtpserver.cpp:25:
/home/pi/rtpmidid/include/rtpmidid/exceptions.hpp:22:10: fatal error: fmt/format.h: No such file or directory
#include <fmt/format.h>
^~~~~~~~~~~~~~
make[3]: *** [lib/CMakeFiles/rtpmidid-shared.dir/build.make:76: lib/CMakeFiles/rtpmidid-shared.dir/rtpclient.cpp.o] Error 1
compilation terminated.
make[3]: *** [lib/CMakeFiles/rtpmidid-static.dir/build.make:89: lib/CMakeFiles/rtpmidid-static.dir/rtpserver.cpp.o] Error 1
In file included from /home/pi/rtpmidid/lib/rtpserver.cpp:25:
/home/pi/rtpmidid/include/rtpmidid/exceptions.hpp:22:10: fatal error: fmt/format.h: No such file or directory
#include <fmt/format.h>
^~~~~~~~~~~~~~
In file included from /home/pi/rtpmidid/include/rtpmidid/iobytes.hpp:21,
from /home/pi/rtpmidid/lib/rtpclient.cpp:32:
/home/pi/rtpmidid/include/rtpmidid/./exceptions.hpp:22:10: fatal error: fmt/format.h: No such file or directory
#include <fmt/format.h>
^~~~~~~~~~~~~~
compilation terminated.
rtpmidid rasberrypi to OSX, import not working but export is.
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 Setup GUI.
-Start rtpmidid on the RPi.
-> Two ALSA midi ports appear on the RPi with the names Network and net1.
-connect a MIDI monitor process to the net1 port 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 Setup GUI.
-Start rtpmidid on the RPi.
-> Two ALSA midi ports appears on the RPi with the names Network and net1.
-Use the Mac GUI to connect the raspberrypi entry 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 net1 port
-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 Network port 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
duplicate mdns browse entries
this might lead to other issues?
it looks like its the same service twice, and this leads to the error/warning
[2019-11-22T19:31:20Z] [rtpmidid.cpp:181] Trying to add again rtpmidi 192.168.1.94:5004 server. Quite probably mDNS re announce. Maybe somebody ask, or just periodically.
Ive checked its not an Ipv6 vs Ipv4
its feels like there should be a way to differentiate between the the two services, and make them unique?
patch@patchbox:~/projects/rtpmidid/build $ ./src/rtpmidid
[2019-11-22T19:31:20Z] [main.cpp:46] Real Time Protocol Music Instrument Digital Interface Daemon - alpha 19.05
[2019-11-22T19:31:20Z] [main.cpp:47] (C) 2019 David Moreno Montero <[email protected]>
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:85] watch_new 5 1
[2019-11-22T19:31:20Z] [rtpserver.cpp:84] Listening RTP MIDI connections at 0.0.0.0:5004, with name: 'patchbox'
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:276] (Browser) NEW: service 'bear' of type '_apple-midi._udp' in domain 'local'
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:276] (Browser) NEW: service 'bear' of type '_apple-midi._udp' in domain 'local'
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:290] (Browser) CACHE_EXHAUSTED
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:229] Service 'bear' of type '_apple-midi._udp' in domain 'local'
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:248] bear.local:5004 (192.168.1.94)
TXT=
cookie is 0
is_local: false
our_own: false
wide_area: false
multicast: true
cached: true
[2019-11-22T19:31:20Z] [rtpmidid.cpp:191] New alsa port: 1, connects to 192.168.1.94:5004 (bear)
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:229] Service 'bear' of type '_apple-midi._udp' in domain 'local'
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:248] bear.local:5004 (192.168.1.94)
TXT=
cookie is 0
is_local: false
our_own: false
wide_area: false
multicast: true
cached: true
[2019-11-22T19:31:20Z] [rtpmidid.cpp:181] Trying to add again rtpmidi 192.168.1.94:5004 server. Quite probably mDNS re announce. Maybe somebody ask, or just periodically.
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:276] (Browser) NEW: service 'patchbox' of type '_apple-midi._udp' in domain 'local'
[2019-11-22T19:31:20Z] [mdns_rtpmidi.cpp:276] (Browser) NEW: service 'patchbox' of type '_apple-midi._udp' in domain 'local'
[2019-11-22T19:31:21Z] [mdns_rtpmidi.cpp:58] Service '/Client7/EntryGroup1' successfully established
[2019-11-22T19:31:21Z] [mdns_rtpmidi.cpp:225] Received own announcement
[2019-11-22T19:31:21Z] [mdns_rtpmidi.cpp:225] Received own announcement
[2019-11-22T19:31:21Z] [mdns_rtpmidi.cpp:290] (Browser) ALL_FOR_NOW
Unknow Issue Building from Source
Building from source gives a strange error: "/usr/include/fmt/core.h:1581:7: note: ‘formattable’ evaluates to false".
All dependencies are met. OS: Arch x64 running 6.4.12-arch1-1 kernel.
Any suggestions?
poller exception - NO not implemented
[2019-11-22T17:42:32Z] [rtpclient.cpp:122] Connecting control port 55192 to 192.168.1.94:5004
FF FF 4E 4F 00 00 00 02 0B 3A 48 21 99 CD 42 47
..NO .... .:H! ..BG
[2019-11-22T17:42:32Z] [poller.cpp:147] Catched exception at poller: Not Implemented
this is caused by macOS rejecting a connection, and NO is not implemented in rtppeer
if you point me to the relevant bit in spec on how to parse NO, id be happy to implement.
(hopefully the NO reply will give is more info as to WHY macOS is rejecting)
rtpmidid::rtppeer::parse_command
switch(command){
case rtppeer::OK:
parse_command_ok(buffer, port);
break;
case rtppeer::IN:
parse_command_in(buffer, port);
break;
case rtppeer::CK:
parse_command_ck(buffer, port);
break;
case rtppeer::BY:
parse_command_by(buffer, port);
break;
default:
buffer.print_hex(true);
throw not_implemented();
}
}
statc
Catchpoint 1 (exception thrown), 0x76db4948 in __cxa_throw () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
(gdb) bt
#0 0x76db4948 in __cxa_throw () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#1 0x000e8794 in rtpmidid::rtppeer::parse_command (this=0x15c750, buffer=..., port=rtpmidid::rtppeer::CONTROL_PORT) at /home/patch/projects/rtpmidid/src/rtppeer.cpp:112
#2 0x000e84cc in rtpmidid::rtppeer::data_ready (this=0x15c750, buffer=..., port=rtpmidid::rtppeer::CONTROL_PORT) at /home/patch/projects/rtpmidid/src/rtppeer.cpp:62
#3 0x000ed5dc in rtpmidid::rtpclient::data_ready (this=0x15c750, port=rtpmidid::rtppeer::CONTROL_PORT) at /home/patch/projects/rtpmidid/src/rtpclient.cpp:176
#4 0x000eca58 in rtpmidid::rtpclient::<lambda(int)>::operator()(int) const (__closure=0x15bdfc) at /home/patch/projects/rtpmidid/src/rtpclient.cpp:88
#5 0x000edd1c in std::_Function_handler<void(int), rtpmidid::rtpclient::connect_to(std::__cxx11::string, uint16_t)::<lambda(int)> >::_M_invoke(const std::_Any_data &, int &&) (
__functor=..., __args#0=@0x7effee08: 12) at /usr/include/c++/8/bits/std_function.h:297
#6 0x000ce4f8 in std::function<void (int)>::operator()(int) const (this=0x15bdfc, __args#0=12) at /usr/include/c++/8/bits/std_function.h:687
#7 0x000cba84 in rtpmidid::poller_t::wait (this=0x136838 <rtpmidid::poller>) at /home/patch/projects/rtpmidid/src/poller.cpp:145
#8 0x00094bfc in main (argc=1, argv=0x7efff204) at /home/patch/projects/rtpmidid/src/main.cpp:55
Inconsistent connection of multiple clients
I have a mioXL that exports a number of connections via rtpmidi. When I try and see those using rtpmidid they're all listed (eg aconnect -l shows them). When I connect to them with alsa based connections (even a simple mido-based python script which uses rtmidi as a backend to alsa) one or more of the connections will usually land in a bad state.
I get a fair few not connected yet messages. And often lots of feedback messages.
I do sometimes see some 'NO' refusals. Not always. Though it's easy for them to get lost in logs.
I tried increasing connection timeouts in code and a couple of other things. But I can't quite see what's going on. It felt a bit like there was a race somewhere. But I can't see it by looking at the code rn.
Do you have any idea what might be going on?
It seems like once it gets into a not connected yet stage it doesn't retry connecting.
Is there a way to have rtpmidid try and reconnect even if it gets no?
This looks super promising. I just can't get it to reliably enough connect right yet.
Thanks
George
crash in alsa after some time. archlinux
Hey, thank you for writing this software, i'm working on using it to forward MIDI to a raspberry pi which is hooked up to an LED strip.
Working great except for this crash that seems to happen after some time. Further attempts to restart the service just keep failing with this
Is this issue further upstream? Trying to understand where in the stack this might be failing. it works for some time perfectly fine, but eventually it fails
OS: Arch Linux x86_64
Kernel: 5.19.2-arch1-1
Aug 20 23:43:11 sreich-archlinux-desktop systemd[1]: Started rtpmidid.
Aug 20 23:43:11 sreich-archlinux-desktop rtpmidid[35245]: [main.cpp:54] Real Time Protocol Music Instrument Digital Interface Dae>
Aug 20 23:43:11 sreich-archlinux-desktop rtpmidid[35245]: [main.cpp:56] (C) 2019-2021 David Moreno Montero [email protected]
Aug 20 23:43:11 sreich-archlinux-desktop rtpmidid[35245]: [alsa/seq_hw.c:466] open /dev/snd/seq failed: Cannot allocate memory
Aug 20 23:43:11 sreich-archlinux-desktop rtpmidid[35245]: [main.cpp:68] Can't open sequencer. Maybe user has no permissions.
Aug 20 23:43:11 sreich-archlinux-desktop systemd[1]: rtpmidid.service: Main process exited, code=exited, status=1/FAILURE
Aug 20 23:43:11 sreich-archlinux-desktop systemd[1]: rtpmidid.service: Failed with result 'exit-code'.
Aug 20 23:43:11 sreich-archlinux-desktop systemd[1]: rtpmidid.service: Scheduled restart job, restart counter is at 5.
Aug 20 23:43:11 sreich-archlinux-desktop systemd[1]: Stopped rtpmidid.
Aug 20 23:43:11 sreich-archlinux-desktop systemd[1]: rtpmidid.service: Start request repeated too quickly.
Aug 20 23:43:11 sreich-archlinux-desktop systemd[1]: rtpmidid.service: Failed with result 'exit-code'.
Aug 20 23:43:11 sreich-archlinux-desktop systemd[1]: Failed to start rtpmidid.
lines 957-1000/1000 (END)
rtpmidid --version
[2022-08-21T03:51:53Z] [main.cpp:54] Real Time Protocol Music Instrument Digital Interface Daemon - 21.119geab5c
[2022-08-21T03:51:53Z] [main.cpp:56] (C) 2019-2021 David Moreno Montero [email protected]
[2022-08-21T03:51:53Z] [config.cpp:91] rtpmidid version 21.119geab5c
pipewire --version
pipewire
Compiled with libpipewire 0.3.56
Linked with libpipewire 0.3.56
Malformed SysEx message in buffer has no end byte
Hi!
Thank you for this project :)
I'd like to report something that looks like a bug.
I'm using an iOS app (Patch Base - https://coffeeshopped.com/patch-base) to control my DSI Evolver.
After experiencing the bug explained below I tried the same on a Windows 7 partition I have using this implementation:
http://www.tobias-erichsen.de/software/rtpmidi.html
..which works just fine.
Ok, the bug. Patch Base allows for randomizing all parameters and sending them to the synth. This doesn't work and my syslog reports the following:
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:44Z] [rtppeer.cpp:496]#033[0m Send feedback to the other end. Journal parsed. Seqnum 21107
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:44Z] [rtppeer.cpp:361]#033[0m Got feedback until package 20832 / 20832. No journal, so ignoring.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;33m[2021-09-12T16:54:45Z] [rtppeer.cpp:401]#033[0m This RTP MIDI header has journal. WIP.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[1;34m80 61 52 75 00 1D 37 EE 7B C1 76 91 43 80 35 00
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0m20 52 75 00 07 08 81 F1 35 64
Sep 12 18:54:59 studio rtpmidid[6569]: #033[1;34m.aRu ..7. {.v. C.5.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0m Ru. .... 5d
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:45Z] [rtppeer.cpp:542]#033[0m I got data from seqnum 21109. 0 channels.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:45Z] [rtppeer.cpp:496]#033[0m Send feedback to the other end. Journal parsed. Seqnum 21109
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;33m[2021-09-12T16:54:45Z] [rtppeer.cpp:401]#033[0m This RTP MIDI header has journal. WIP.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[1;34m80 61 52 77 00 1D 54 AA 7B C1 76 91 43 80 35 00
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0m20 52 77 00 07 08 81 F1 35 64
Sep 12 18:54:59 studio rtpmidid[6569]: #033[1;34m.aRw ..T. {.v. C.5.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0m Rw. .... 5d
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:45Z] [rtppeer.cpp:542]#033[0m I got data from seqnum 21111. 0 channels.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:45Z] [rtppeer.cpp:496]#033[0m Send feedback to the other end. Journal parsed. Seqnum 21111
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:47Z] [rtppeer.cpp:361]#033[0m Got feedback until package 20834 / 20834. No journal, so ignoring.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;33m[2021-09-12T16:54:47Z] [rtppeer.cpp:401]#033[0m This RTP MIDI header has journal. WIP.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[1;34m80 61 52 79 00 1D 7F 32 7B C1 76 91 43 80 35 00
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0m20 52 79 00 07 08 81 F1 35 64
Sep 12 18:54:59 studio rtpmidid[6569]: #033[1;34m.aRy ...2 {.v. C.5.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0m Ry. .... 5d
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:47Z] [rtppeer.cpp:542]#033[0m I got data from seqnum 21113. 0 channels.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:47Z] [rtppeer.cpp:496]#033[0m Send feedback to the other end. Journal parsed. Seqnum 21113
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;33m[2021-09-12T16:54:47Z] [rtppeer.cpp:401]#033[0m This RTP MIDI header has journal. WIP.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[1;34m80 61 52 7B 00 1D 99 0E 7B C1 76 91 43 80 35 00
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0m20 52 7B 00 07 08 81 F1 35 64
Sep 12 18:54:59 studio rtpmidid[6569]: #033[1;34m.aR{ .... {.v. C.5.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0m R{. .... 5d
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:47Z] [rtppeer.cpp:542]#033[0m I got data from seqnum 21115. 0 channels.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:47Z] [rtppeer.cpp:496]#033[0m Send feedback to the other end. Journal parsed. Seqnum 21115
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;33m[2021-09-12T16:54:48Z] [rtppeer.cpp:401]#033[0m This RTP MIDI header has journal. WIP.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[1;34m80 61 52 7D 00 1D BF 81 7B C1 76 91 43 80 35 00
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0m20 52 7D 00 07 08 81 F1 35 64
Sep 12 18:54:59 studio rtpmidid[6569]: #033[1;34m.aR} .... {.v. C.5.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0m R}. .... 5d
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:48Z] [rtppeer.cpp:542]#033[0m I got data from seqnum 21117. 0 channels.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:48Z] [rtppeer.cpp:496]#033[0m Send feedback to the other end. Journal parsed. Seqnum 21117
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:48Z] [rtppeer.cpp:361]#033[0m Got feedback until package 20835 / 20835. No journal, so ignoring.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;33m[2021-09-12T16:54:49Z] [rtppeer.cpp:401]#033[0m This RTP MIDI header has journal. WIP.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[1;34m80 61 52 7F 00 1D D7 70 7B C1 76 91 43 80 35 00
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0m20 52 7F 00 07 08 81 F1 35 64
Sep 12 18:54:59 studio rtpmidid[6569]: #033[1;34m.aR. ...p {.v. C.5.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0m R.. .... 5d
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:49Z] [rtppeer.cpp:542]#033[0m I got data from seqnum 21119. 0 channels.
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:49Z] [rtppeer.cpp:496]#033[0m Send feedback to the other end. Journal parsed. Seqnum 21119
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;37m[2021-09-12T16:54:50Z] [rtppeer.cpp:295]#033[0m Latency Helene’s iPad: 4.90 ms (server / 3)
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:59Z] [rtppeer.cpp:396]#033[0m Long header, 68 bytes long
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;33m[2021-09-12T16:54:59Z] [rtpmidid.cpp:437]#033[0m Malformed SysEx message in buffer has no end byte
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:59Z] [rtppeer.cpp:396]#033[0m Long header, 34 bytes long
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;33m[2021-09-12T16:54:59Z] [rtpmidid.cpp:437]#033[0m Malformed SysEx message in buffer has no end byte
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:59Z] [rtppeer.cpp:396]#033[0m Long header, 69 bytes long
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;33m[2021-09-12T16:54:59Z] [rtpmidid.cpp:437]#033[0m Malformed SysEx message in buffer has no end byte
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:59Z] [rtppeer.cpp:396]#033[0m Long header, 34 bytes long
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;33m[2021-09-12T16:54:59Z] [rtpmidid.cpp:437]#033[0m Malformed SysEx message in buffer has no end byte
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:59Z] [rtppeer.cpp:396]#033[0m Long header, 38 bytes long
Sep 12 18:54:59 studio rtpmidid[6569]: #033[0;34m[2021-09-12T16:54:59Z] [rtppeer.cpp:396]#033[0m Long header, 33 bytes long
I tried to record the SysEx being sent to the synth, and if I got it correctly it looks like this:
F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F7 44 01 47 57 2D 00 00 0D 33 17 00 3E 0C 48 31 01 09 44 12 04 40 00 2E 1F 34 1F 2B 69 60 00 04 18 F0 00 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7 F0 00 F7
I recorded this using MidiOx running with Wine 6.
I'm no expert on SysEx, but happy to provide further debug info it it can help this issue.
Cheers
EDIT 1
❯ cat /proc/version
Linux version 5.4.0-80-lowlatency (buildd@lcy01-amd64-030) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #90-Ubuntu SMP PREEMPT Fri Jul 9 23:56:54 UTC 2021
❯ lsb_release -a
No LSB modules are available.
Distributor ID: Linuxmint
Description: Linux Mint 20.2
Release: 20.2
Codename: uma
❯ apt show rtpmidid
Package: rtpmidid
Version: 21.07
Status: install ok installed
Priority: optional
Section: unknown
Maintainer: David Moreno <[email protected]>
Installed-Size: 915 kB
Depends: python3
Homepage: https://github.com/davidmoreno/rtpmidid
Download-Size: unknown
APT-Manual-Installed: yes
APT-Sources: /var/lib/dpkg/status
Description: Real Time Protocol Musical Instrument Digital Interface Daemon (RTP-MIDI)
rtpmidid allows you to share ALSA sequencer devices on the network using RTP
MIDI, and import other network shared RTP MIDI devices.
.
rtpmidid is an user daemon, and when a RTP MIDI device is announced using mDNS
(also known as Zeroconf, Avahi, and multicast DNS) it exposes this ALSA
sequencer port.
EDIT 2
This looks very much to be related to this line
Line 449 in 6403795
rtpmidid.service coredump
On Ubuntu 21.04 server (Linux ubuntu-vbox 5.11.0-31-generic) in a VirtualBox (Version 6.1.26 r145957) running on a Windows 10 host.
I built rtpmidid from git, and installed the deb's
Aug 21 08:08:57 ubuntu-vbox systemd[1]: Started rtpmidid.
Aug 21 08:08:57 ubuntu-vbox rtpmidid[27313]: rtpmidid: browser.c:583: avahi_service_browser_new: Assertion `client' failed.
Aug 21 08:08:57 ubuntu-vbox systemd[1]: rtpmidid.service: Main process exited, code=dumped, status=6/ABRT
Aug 21 08:08:57 ubuntu-vbox systemd[1]: rtpmidid.service: Failed with result 'core-dump'.
Aug 21 08:08:57 ubuntu-vbox systemd[1]: rtpmidid.service: Scheduled restart job, restart counter is at 1.
Aug 21 08:08:57 ubuntu-vbox systemd[1]: Stopped rtpmidid.
Aug 21 08:08:57 ubuntu-vbox systemd[1]: Started rtpmidid.
Aug 21 08:08:57 ubuntu-vbox rtpmidid[27364]: rtpmidid: browser.c:583: avahi_service_browser_new: Assertion `client' failed.
Aug 21 08:08:57 ubuntu-vbox systemd[1]: rtpmidid.service: Main process exited, code=dumped, status=6/ABRT
Aug 21 08:08:57 ubuntu-vbox systemd[1]: rtpmidid.service: Failed with result 'core-dump'.
etc.
Can you help troubleshoot - it's a server install, but I think midi is configured in the kernel.
grep -i MIDI /boot/config-5.11.0-31-generic
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQ_MIDI_EVENT=m
CONFIG_SND_SEQ_MIDI=m
CONFIG_SND_SEQ_MIDI_EMUL=m
CONFIG_SND_SEQ_VIRMIDI=m
CONFIG_SND_VIRMIDI=m
CONFIG_USB_F_MIDI=m
CONFIG_USB_CONFIGFS_F_MIDI=y
CONFIG_USB_MIDI_GADGET=m
I don't know where to go from here.
port connection fails when connecting many ports in quick succession
Hi, I'm using rtpmidid to implement a patchbay to route connections through a Raspberry Pi. I've written a version of aconnect that allows me to serialize and deserialize a group of ALSA port connections to a TOML file so that I can save and recreate a complex rtpMIDI routing.
So far this is working great except for one issue. When restoring a group of connections from many outputs (from an iConnectivity MioXL) to the same input (Windows rtpMIDI), the connection appears in the Windows rtpMIDI connection list but is greyed out. I tried adding std::this_thread::sleep_for(0.5s) after each connection and all connections were then restored properly. Seems like there might be some kind of race condition going on, either with alsa seq or rtpmidid. Any idea why this might be happening?
I'm happy to post code for my aconnect version with instructions so you can try the utility, but it's very much an undocumented work in progress so I thought I'd check for a quick solution here first. Let me know if there's any other info that would be helpful. Thanks!
windows session close - terminate called after throwing an instance of 'std::bad_function_call'
[2019-11-23T14:27:12Z] [main.cpp:47] (C) 2019 David Moreno Montero <[email protected]>
[2019-11-23T14:27:12Z] [mdns_rtpmidi.cpp:85] watch_new 5 1
[2019-11-23T14:27:12Z] [rtpserver.cpp:84] Listening RTP MIDI connections at 0.0.0.0:5004, with name: 'patchbox'
[2019-11-23T14:27:12Z] [mdns_rtpmidi.cpp:280] (Browser) NEW: service 'bear' of type '_apple-midi._udp' in domain 'local'
[2019-11-23T14:27:12Z] [mdns_rtpmidi.cpp:294] (Browser) CACHE_EXHAUSTED
[2019-11-23T14:27:12Z] [mdns_rtpmidi.cpp:229] Service 'bear' of type '_apple-midi._udp' in domain 'local'
[2019-11-23T14:27:12Z] [mdns_rtpmidi.cpp:250] bear.local:5004 (192.168.1.94)
interface=2
TXT=
cookie is 0
is_local: false
our_own: false
wide_area: false
multicast: true
cached: true
[2019-11-23T14:27:12Z] [rtpmidid.cpp:191] New alsa port: 1, connects to 192.168.1.94:5004 (bear)
[2019-11-23T14:27:12Z] [mdns_rtpmidi.cpp:280] (Browser) NEW: service 'patchbox' of type '_apple-midi._udp' in domain 'local'
[2019-11-23T14:27:13Z] [mdns_rtpmidi.cpp:58] Service '/Client4/EntryGroup1' successfully established
[2019-11-23T14:27:13Z] [mdns_rtpmidi.cpp:225] Received own announcement
[2019-11-23T14:27:13Z] [mdns_rtpmidi.cpp:294] (Browser) ALL_FOR_NOW
[2019-11-23T14:27:17Z] [mdns_rtpmidi.cpp:280] (Browser) NEW: service 'PERRO' of type '_apple-midi._udp' in domain 'local'
[2019-11-23T14:27:17Z] [mdns_rtpmidi.cpp:229] Service 'PERRO' of type '_apple-midi._udp' in domain 'local'
[2019-11-23T14:27:17Z] [mdns_rtpmidi.cpp:250] PERRO.local:5004 (192.168.1.13)
interface=2
TXT=
cookie is 0
is_local: false
our_own: false
wide_area: false
multicast: true
cached: true
[2019-11-23T14:27:17Z] [rtpmidid.cpp:191] New alsa port: 2, connects to 192.168.1.13:5004 (PERRO)
[2019-11-23T14:27:27Z] [mdns_rtpmidi.cpp:289] (Browser) REMOVE: service 'PERRO' of type '_apple-midi._udp' in domain 'local'
terminate called after throwing an instance of 'std::bad_function_call'
what(): bad_function_call
Aborted
caused by
/home/patch/projects/rtpmidid/src/mdns_rtpmidi.cpp:290
presumably bad function pointed.
Catchpoint 1 (exception thrown), 0x76db4948 in __cxa_throw () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
(gdb) bt
#0 0x76db4948 in __cxa_throw () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#1 0x76ddd680 in std::__throw_bad_function_call() () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#2 0x000d822c in std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (this=0x7efff058, __args#0="PERRO") at /usr/include/c++/8/bits/std_function.h:686
#3 0x000d54a0 in browse_callback (b=0x156d88, interface=2, protocol=0, event=AVAHI_BROWSER_REMOVE, name=0x15b804 "PERRO", type=0x15b810 "_apple-midi._udp", domain=0x15b828 "local",
flags=AVAHI_LOOKUP_RESULT_MULTICAST, userdata=0x7efff030) at /home/patch/projects/rtpmidid/src/mdns_rtpmidi.cpp:290
#4 0x76e90f68 in avahi_service_browser_event () from /usr/lib/arm-linux-gnueabihf/libavahi-client.so.3
Backtrace stopped: Cannot access memory at address 0x6c69613e
(gdb)
channel pressure not supported
avahi branch
warning -> 'This event type 12 is not managed yet'
aseq.cpp.
I'll have a look to see if this is easy to add, I need this as I'm trying to send MPE midi over the connection.
am i good to add this to the avahi branch?
raspberryPI connecting to macOS : Try to access end of buffer exception
with a raspberryPI connecting to macOS, Im seeing "Try to access end of buffer " exceptions/errors, using GDB ive tracked it down to here:
Breakpoint 1, rtpmidid::parse_buffer_t::check_enought (this=0x7effe59c, nbytes=193) at /home/patch/projects/3rdparty/rtpmidid/src/./netutils.hpp:44
44 throw exception("Try to access end of buffer at {}", (position - start) + nbytes);
(gdb) bt
#0 rtpmidid::parse_buffer_t::check_enought (this=0x7effe59c, nbytes=193) at /home/patch/projects/3rdparty/rtpmidid/src/./netutils.hpp:44
#1 0x00125424 in rtpmidid::parse_buffer_t::copy_from (this=0x7effe59c, from=..., chars=193) at /home/patch/projects/3rdparty/rtpmidid/src/./netutils.hpp:174
#2 0x00125250 in rtpmidid::read_label (buffer=..., label=...) at /home/patch/projects/3rdparty/rtpmidid/src/netutils.cpp:60
#3 0x00108d48 in read_answer (server=0x7effef80, buffer=...) at /home/patch/projects/3rdparty/rtpmidid/src/mdns.cpp:121
#4 0x0010a3e4 in parse_packet (mdns=0x7effef80, parse_buffer=...) at /home/patch/projects/3rdparty/rtpmidid/src/mdns.cpp:400
#5 0x0010a560 in rtpmidid::mdns::mdns_ready (this=0x7effef80) at /home/patch/projects/3rdparty/rtpmidid/src/mdns.cpp:445
If I get time, I'll try to investigate some more
Crash log: Segmentation fault in rtpmidid::rtpserver::get_peer_by_ssrc
Hi,
I've been running rtpmidid (latest version git describe: v20.07-16-g88acef4) on a raspberry pi 3B+ with Raspbian buster - I've connected the to rtpmidid from my MacBook (MacOS10.14.6) using Audio MIDI Setup and I'm sending MIDI from Ableton Live. I'm seeing it crash fairly regularly when complied in Release version. I've run it from gdb and I've shown a stacktrace (log below). I've tried compiling the debug version and running that but it doesn't crash so I'm finding it hard to get much further.
[2020-12-29T11:50:14Z] [rtppeer.cpp:401] This RTP MIDI header has journal. WIP.
80 61 43 49 3B 5C F2 15 E4 48 A9 0A 43 81 43 40
20 00 01 08 08 08 01 88 43 64 CA
.aCI ;.. .H.. C.C@
... .... Cd.
[2020-12-29T11:50:14Z] [rtppeer.cpp:534] I got data from seqnum 1. 0 channels.
[2020-12-29T11:50:14Z] [rtppeer.cpp:488] Send feedback to the other end. Journal parsed. Seqnum 1
[2020-12-29T11:50:14Z] [rtppeer.cpp:401] This RTP MIDI header has journal. WIP.
80 61 43 4A 3B 5D 03 2C E4 48 A9 0A 43 91 44 64
20 00 01 08 06 08 00 88 DA
.aCJ ;]., .H.. C.Dd
... .... .
[2020-12-29T11:50:14Z] [rtppeer.cpp:534] I got data from seqnum 1. 0 channels.
[2020-12-29T11:50:14Z] [rtppeer.cpp:488] Send feedback to the other end. Journal parsed. Seqnum 1Program received signal SIGSEGV, Segmentation fault.
0x000601f4 in rtpmidid::rtpserver::get_peer_by_ssrc(unsigned int) ()
(gdb) where
#0 0x000601f4 in rtpmidid::rtpserver::get_peer_by_ssrc(unsigned int) ()
#1 0x00061d10 in rtpmidid::rtpserver::get_peer_by_packet(rtpmidid::io_bytes_reader&, rtpmidid::rtppeer::port_e) ()
#2 0x00061ebc in rtpmidid::rtpserver::data_ready(rtpmidid::rtppeer::port_e) ()
#3 0x000648d8 in rtpmidid::poller_t::wait() ()
#4 0x0002a5dc in main ()
active sense - not implemented
this clogs up the logs for some devices.
I suspect, at least initially, active sense is not important to route (but i guess should be).
(certainly should not be journaled)
do we ignore for now?
rtpmidid: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by rtpmidid)
Hi there,
I don't know if you guys have tried your program in Debian Buster Stable repos , but is not working.
rtpmidid: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by rtpmidid)
That library is not available on Debian estable repositories I am afraid. Any work around?
https://stackoverflow.com/questions/44773296/libstdc-so-6-version-glibcxx-3-4-20-not-found#46613656
Thank you
MPC Port
@davidmoreno As you might now, the MPC is running a buildroot-based Linux and it is possible to install 3rd party utilities onto the Filesystem (and activate SSH). I have found your project and I think it would be interesting to create a statically-linked version for the armhf architecture so it can be used on the MPC. I've seen your comment about the MPC on one of the releases, and I think it would be a nice addon!
rtpmidid:armhf depends on python3
Trying to install this on my RPI3 Running Rpi OS Lite 64 Bit.
sudo wget https://github.com/davidmoreno/rtpmidid/releases/download/v21.11/rtpmidid_21.11_armhf.deb
sudo dpkg -i rtpmidid_21.11_armhf.deb
but:
Preparing to unpack rtpmidid_21.11_armhf.deb ...
Unpacking rtpmidid:armhf (21.11) over (20.07) ...
dpkg: dependency problems prevent configuration of rtpmidid:armhf:
rtpmidid:armhf depends on python3.
dpkg: error processing package rtpmidid:armhf (--install):
dependency problems - leaving unconfigured
Processing triggers for man-db (2.9.4-2) ...
Errors were encountered while processing:
rtpmidid:armhf
Its a fresh install, when I run
python3 --version
Python 3.9.2
Now if I run
`sudo apt --fix-broken install
This will remove some packages that are needed for other libraries. But it will complete the installation of rtpmidid after.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:
flashrom gir1.2-glib-2.0 gir1.2-packagekitglib-1.0 libappstream4 libftdi1-2 libgirepository-1.0-1 libglib2.0-bin libpackagekit-glib2-18 libpython3-stdlib libstemmer0d
libtalloc2 libtevent0 libwbclient0 packagekit packagekit-tools python-apt-common python3-debconf python3-distro-info rpi.gpio-common
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
gcc-10-base:armhf krb5-locales libbz2-1.0:armhf libc6:armhf libcom-err2:armhf libcrypt1:armhf libdb5.3:armhf libexpat1:armhf libffi7:armhf libgcc-s1:armhf libgpm2:armhf
libgssapi-krb5-2:armhf libidn2-0:armhf libk5crypto3:armhf libkeyutils1:armhf libkrb5-3:armhf libkrb5support0:armhf liblzma5:armhf libmpdec3:armhf libncursesw6:armhf
libnsl2:armhf libnss-nis:armhf libnss-nisplus:armhf libpython3-stdlib:armhf libpython3.9-minimal:armhf libpython3.9-stdlib:armhf libreadline8:armhf libsqlite3-0:armhf
libssl1.1:armhf libstdc++6:armhf libtinfo6:armhf libtirpc3:armhf libunistring2:armhf libuuid1:armhf python3:armhf python3-minimal:armhf python3.9:armhf
python3.9-minimal:armhf uuid-runtime zlib1g:armhf
Suggested packages:
glibc-doc:armhf locales:armhf gpm:armhf krb5-doc:armhf krb5-user:armhf python3-doc:armhf python3-tk:armhf python3-venv:armhf python3.9-venv:armhf python3.9-doc:armhf
binutils:armhf binfmt-support:armhf
The following packages will be REMOVED:
apt-listchanges cifs-utils python-is-python3 python3 python3-apt python3-dbus python3-gi python3-minimal python3-pycurl python3-rpi.gpio python3-software-properties
python3-spidev python3.9 python3.9-minimal rpi-eeprom software-properties-common unattended-upgrades
The following NEW packages will be installed:
gcc-10-base:armhf krb5-locales libbz2-1.0:armhf libc6:armhf libcom-err2:armhf libcrypt1:armhf libdb5.3:armhf libexpat1:armhf libffi7:armhf libgcc-s1:armhf libgpm2:armhf
libgssapi-krb5-2:armhf libidn2-0:armhf libk5crypto3:armhf libkeyutils1:armhf libkrb5-3:armhf libkrb5support0:armhf liblzma5:armhf libmpdec3:armhf libncursesw6:armhf
libnsl2:armhf libnss-nis:armhf libnss-nisplus:armhf libpython3-stdlib:armhf libpython3.9-minimal:armhf libpython3.9-stdlib:armhf libreadline8:armhf libsqlite3-0:armhf
libssl1.1:armhf libstdc++6:armhf libtinfo6:armhf libtirpc3:armhf libunistring2:armhf libuuid1:armhf python3:armhf python3-minimal:armhf python3.9:armhf
python3.9-minimal:armhf uuid-runtime zlib1g:armhf
0 upgraded, 40 newly installed, 17 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 12.9 MB of archives.
After this operation, 1,107 kB of additional disk space will be used.
Do you want to continue? [Y/n] ^C
How do I install rtpmidid without removing these packages?
Getting "Unknown peer" on session disconnect
When a remote client disconnects, I'm seeing the message "Unknown peer (IP address details), and not connect on control". The connection is torn down from the client side; but it lives forever in rtpmidid until it is terminated and restarted.
I think this is because at line 168 in rtpserver.cpp the initiator id is being taken from the third uint32; but in the BY message that is always zero.
I can repeat this behaviour using rtpMIDI for Windows and the built-in Mac MIDI utilities. The test_rtpserver test also fails.
Looking at the control message, it is the fourth uint32 that is common between the IN and BY control messages but I'm not familiar enough with MIDI (and MIDI in RTP) to say whether that's the right value to use when terminating the session. Certainly if I change line 168 from +8 to +12 it does not go well ;-) and I'm reluctant to make wholesale changes just to fix this one issue.
My environment is Ubuntu 20.04 - have not tested on any other distro.
Garbled text in --help message
Looks like there's a line end (\n) missing here:
Line 40 in c77c69c
Also, maybe reword to something like "This option is the default, no need to specify it explicitly." (and perhaps make that a new line, so that the option isn't broken awkwardly in an 80 characters terminal).
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.