Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is the timestamp in handle_timestamp() incorrect? #34

Open
Brettles opened this issue Aug 28, 2023 · 0 comments
Open

Is the timestamp in handle_timestamp() incorrect? #34

Brettles opened this issue Aug 28, 2023 · 0 comments

Comments

@Brettles
Copy link

I'm looking at line 156 of protocol.py:

now = int(time.time() * 10000)

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant