This matches the behaviour of the other instance of the invocation of the MIM_LONGDATA callback. It's rather difficult to reliably write a test for this, but it has been observed to be the case on Windows. Signed-off-by: Huw Davies <huw(a)codeweavers.com> --- dlls/winecoreaudio.drv/midi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dlls/winecoreaudio.drv/midi.c b/dlls/winecoreaudio.drv/midi.c index 4eb68c8b1d7..ab861d44525 100644 --- a/dlls/winecoreaudio.drv/midi.c +++ b/dlls/winecoreaudio.drv/midi.c @@ -159,7 +159,7 @@ static DWORD MIDIIn_Reset(WORD wDevID) lpMidiHdr->dwFlags &= ~MHDR_INQUEUE; lpMidiHdr->dwFlags |= MHDR_DONE; /* FIXME: when called from 16 bit, lpQueueHdr needs to be a segmented ptr */ - MIDI_NotifyClient(wDevID, MIM_LONGDATA, (DWORD_PTR)lpMidiHdr, dwTime); + MIDI_NotifyClient(wDevID, MIM_LONGDATA, (DWORD_PTR)lpMidiHdr, dwTime - sources[wDevID].startTime); } midi_lock( FALSE ); -- 2.23.0