krevis
commented
2 years ago To test: in MessageParser.swift in messagesForPacket(), change let timeStamp = packetPtr.pointee.timeStamp to something like MIDITimeStamp(Int64.max) + 1000. That gives us a timestamp which will certainly overflow when converting to nanoseconds, at least on an M1 where the ratio is 125/3.
When encoding and decoding message timestamps, there is potential for error in several ways.
We take host time stamps, convert them to nanoseconds, and encode. Depending on the timebase (e.g. 125/3 on M1 Macs), this is slightly lossy. Test case: on an M1, compare some integer host time stamps across save and reopen. They should be identical, but aren't.
The conversion from host time stamp to nanoseconds may overflow. Both types are
UInt64, and the conversion ratio can be > 1. Since we don't encode the host time stamp itself, an overflow here is catastrophic -- we lose the original value and can never get it back.There is potential for confusion across devices with different timebases. It's not very sensical to get a nanosecond value from a file originated on one machine, then convert it to "host time" using a different machine with a different timebase. Ideally we wouldn't use functions like
AudioConvertNanosToHostTime()which depend on the current machine, but we would instead always pass in an explicit timebase from the original machine.Similar issues with clock time. We currently save clock time in the message itself, but it's the clock time when the message is created, and is not related to the actual timestamp. Is that right? Should we go back to something like
MessageTimeBase, which had the right spirit but the wrong implementation?