Notifications of incoming data are now directly added to a notify
ring-buffer by macOS's midi read callback. The ring-buffer is
implemented with an unused sentinel directly before the read ptr to
distinguish between the full vs empty state. Notifications are
processed by the client's notify thread via the midi_notify_wait
syscall.
Note that the read callback thread is not a Win32 thread, so the
Win32 api cannot be used in anything that it calls.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Currently the thread just blocks until told to quit by midi_release.
Eventually, this thread will dispatch the MIM_DATA and MIM_LONGDATA
notifications and essentially replace the existing RunLoop-based
mechanism.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The motivation is that this will need to be called from a
non-Win32 thread and so shouldn't use the Win32 API. An
added benefit is that it will eliminate the 16ms jitter
associated with GetTickCount().
The instance of the helper on the user-side is temporary.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The headers are removed one at a time so that each notification
can be reported back to the client-side. If there are remaining
headers, the unixlib will return ERROR_RETRY to request that the
client calls again.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
While these could be left on the user-side, it seems simplest to move
everything across.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Notifications are filled out by the unixlib and returned to
the user-side for dispatch.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
midi_init temporarily returns unix-side info, which will eventually
be removed.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is to enable coremidi.c to become the unixlib, while still
enabling code on the user-side to be able to call MIDIOut_Send() for
the time being. Eventually, its equivalent will move to the unixlib
and audiounit.c will disappear.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The Core MIDI MIDIPacket struct is declared with a 256-byte data array,
but this is just for convenience. There may be only one accessible byte,
or there may be more than 256.
Only read 'length' bytes from the packet, and correctly handle a
length > 256.
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Charles Davis <cdavis5x@gmail.com>
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Alexandre Julliard