Notifications
Clear all
Topic starter
Dear All
I'm observing BLE MIDI packets with unexpected timestamps. I'm running Presonus Studio One 5 Pro to send MIDI events from MacOS Monterey. MIDI is sent to a BLE MIDI device peripheral connected to the Mac central.
Below 2 examples of received packets :
Example 1
Packet N (3 bytes)
0xAE 0xDD 0xF8 // Midi clock with time stamp 5981d
Packet N+1 (3 bytes)
0xAE 0xF1 0xF8 // Midi clock with time stamp 6001d
Packet N+2 (5 bytes)
0x80 0x80 0xFC // Midi stop with time stamp 0
0x85 0xF8 // Midi clock with time stamp LSB referring to previous packet (N+1)
20ms between Packets N and N+1 is as expected.
For packet N+2 : Time stamp LSB 0x85 makes 20ms if previous packet Time stamp MSB is used (0xAE). But the specification does not mention to use MSB timestamp of previous packet.
Example 2
Packet N (4 bytes)
0xA0 0xC8 0xF1 0x30 // MTC with time stamp 4168d
Packet N+1 (4 bytes)
0xA0 0xD2 0xF1 0x40 // MTC with time stamp 4178d
Packet N+2 (4 bytes)
0xA0 0xDC 0xF1 0x50 // MTC with time stamp 4188d
Packet N+3 (16 bytes)
0x80 0x80 0xF0 0x7F 0x7F 0x01 0x01 0x20 0x00 0x00 0x00 0x80 0xF7 // MTC Sysex with time stamp 0d
0xE6 0xF1 0x60 // MTC with time stamp LSB only
We can observe a time difference of 10ms on the first 3 packets, this is the expected timing.
On packet N+3, there is a SYSEX with timestamp 0 (Timestamp MSB and LSB are zero), plus a MTC with time stamp LSB only, I assume the time stamp MSB is the one found in the current packet N+3 (MSB = 0), but it seems the timestamp MSB should be the one from the previous packet (N+2).
Is there something I did not understand in BLE MIDI Timestamps ?
Thanks for any help.
Posted : 20/01/2022 3:09 am
Topic starter
Replying to myself with the actual / expected timestamps :
For example 1
Actual is
Packet 1 : 0xAE 0xDD 0xF8 // Midi clock with time stamp 5981d
Packet 2 : 0xAE 0xF1 0xF8 // Midi clock with time stamp 6001d
Packet 3 : 0x80 0x80 0xFC // Midi stop with time stamp 0
0x85 0xF8 // Midi clock with time stamp LSB
Expected would be :
Packet 1 : 0xAE 0xDD 0xF8 // Midi clock with time stamp 5981d
Packet 2 : 0xAE 0xF1 0xF8 // Midi clock with time stamp 6001d
Packet 3 : 0xAE 0xF1 0xFC // Midi stop with time stamp 6001d
0x85 0xF8 // Midi clock with time stamp LSB
So the timestamp of last MIDI clock is 0xAF 0x85.
Since 0x85 is lower than 0xF1 the timestamp LSB overflows in current packet and we must add 1 to the timestamp MSB (0xAE → 0xAF), as mentioned in the specification.
For example 2
Actual is
Packet 1 : 0xA0 0xD2 0xF1 0x40 // MTC with time stamp 4178d
Packet 2 : 0xA0 0xDC 0xF1 0x50 // MTC with time stamp 4188d
Packet 3 : 0x80 0x80 0xF0 0x7F 0x7F 0x01 0x01 0x20 0x00 0x00 0x00 0x80 0xF7 // MTC Sysex with time stamp 0
0xE6 0xF1 0x60 // MTC with time stamp LSB only
Expected would be
Packet 1 : 0xA0 0xD2 0xF1 0x40 // MTC with time stamp 4178d
Packet 2 : 0xA0 0xDC 0xF1 0x50 // MTC with time stamp 4188d
Packet 3 : 0xA0 0xDC 0xF0 0x7F 0x7F 0x01 0x01 0x20 0x00 0x00 0x00 0xDC 0xF7 // MTC Sysex with time stamp 4188d
0xE6 0xF1 0x60 // MTC with time stamp LSB only
By propagating the timestamp MSB 0xA0 to the last packet (instead of timestamp MSB 0x80), the time stamp LSB 0xE6 results in a timestamp 0xA0 0xE6 (4198d) which is 10ms later than the previous MTC event, as expected.
In both examples, we can see the timestamp reseted to zero, while it should not be since the next event is referring to the previous timestamp MSB. From my understanding this does not comply to the monotonic timings mentioned in the specification.
Jerome
Posted : 21/01/2022 2:18 am
