You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know that the standard says that this field is in increments of microseconds, etc. However:
The timestamp in the RTP header is only 32 bits. And the timestamps in each MIDI message that is sent are relative to the timestamps that are negotiated in the original "hello" phase of the session. I know that the RTP MIDI spec calls for 64 bit precision but that can't be right (except during the initial negotiation).
I've done some testing and bunch of packet captures between various different RTP MIDI handlers - so the timestamp might well be in microsecond increments but it has to be round down somehow. The Wikipedia article does say that:
this is not an absolute time, but a time related to a local reference
When I take out the * 10000 all of a sudden all my connections start working. So this is a good thing! ;-)
Anyway. The Linux 32 epoch is also coming up soon so I think that what is needed is to take the time, multiply by 10,000 then mod it by a specific (but constant) value. And this is going to be true everywhere in the code where the timestamp is put into the RTP header.
I'm happy to create a PR for this if you agree (I think it's kind of a big deal to be stumbling around inside the code this much).
The text was updated successfully, but these errors were encountered:
I'm looking at line 156 of protocol.py:
I know that the standard says that this field is in increments of microseconds, etc. However:
The timestamp in the RTP header is only 32 bits. And the timestamps in each MIDI message that is sent are relative to the timestamps that are negotiated in the original "hello" phase of the session. I know that the RTP MIDI spec calls for 64 bit precision but that can't be right (except during the initial negotiation).
I've done some testing and bunch of packet captures between various different RTP MIDI handlers - so the timestamp might well be in microsecond increments but it has to be round down somehow. The Wikipedia article does say that:
When I take out the
* 10000
all of a sudden all my connections start working. So this is a good thing! ;-)Anyway. The Linux 32 epoch is also coming up soon so I think that what is needed is to take the time, multiply by 10,000 then mod it by a specific (but constant) value. And this is going to be true everywhere in the code where the timestamp is put into the RTP header.
I'm happy to create a PR for this if you agree (I think it's kind of a big deal to be stumbling around inside the code this much).
The text was updated successfully, but these errors were encountered: