Problem
When a MIDI device (e.g. a USB master keyboard) is plugged in / switched on after Wine (and a DAW such as Reaper) is already running, it is not detected. The DAW's MIDI device list and its "retry/refresh" do not pick it up; a previously-selected input shows as <not found>. Only restarting Wine/DAW with the device already on makes it appear.
Root cause (confirmed via WINEDEBUG=+midi,+alsa,+winmm trace)
winealsa enumerates MIDI ports once at load time into the static srcs/dests arrays in dlls/winealsa.drv/alsamidi.c. After that:
- winealsa does not subscribe to the ALSA system-announce port, so it never receives
SND_SEQ_EVENT_PORT_START when a new sequencer port appears.
- winmm caches the device count/caps from that one-time enumeration and does not re-query the driver on
midiInGetNumDevs / midiInGetDevCaps.
Net effect: a device not present at Wine start is invisible forever, no matter how often the DAW retries. Confirmed in a trace: at start winealsa enumerated 5 inputs (System, PipeWire×2, Midi Through, M4, nanoKEY2); after switching on an absent KM88 keyboard there was zero activity in the winealsa record thread — no announce event, no PORT_START. Reaper's "retry" re-queried midiInGetDevCapsW for devices 0–4 (the cached set) and never saw a device 5.
Proposed fix — three layers
| Layer |
What |
Reference |
| 1 |
winealsa: subscribe to the system-announce port → receive PORT_START |
part of shibco/ableton-linux patch 0028 |
| 2 |
winealsa: on PORT_START, port_add a brand-new device into srcs/dests (not just re-attach an existing one) |
0028 only re-attaches known devices; it does not add new ones |
| 3 (the hard part) |
winmm: invalidate / refresh its device cache when the driver's device set changes |
Wine has no mechanism for this today — a winealsa→winmm device-change signal + re-enumerate would need to be built |
Layer 3 is the crux. Even with srcs/dests updated in winealsa, a DAW's midiInGetDevCaps / midiInGetNumDevs hits the winmm cache, not the driver — so the new device stays invisible until winmm re-enumerates. Solving only layers 1–2 (winealsa) is not enough; the DAW still won't see the new device.
Related
- shibco/ableton-linux patch 0028 ("re-subscribe MIDI devices when they reappear") solves only the re-attach case (device present at start, briefly removed/replugged). The brand-new-after-start case tracked here is not covered.
- This is a general Wine gap, not specific to this fork.
Workaround (until fixed)
Switch the device on before starting Wine/DAW, so it is present in the one-time static enumeration.
Scope note
This issue concerns the winmm / winealsa (classic MIDI) path used by DAWs such as Reaper. Separately, some applications use the WinRT MIDI API (Windows.Devices.Midi.MidiInPort), which Wine does not implement at all (dlls/ has windows.devices.bluetooth, .enumeration, .usb, windows.media.devices — but no windows.devices.midi). That is a different, larger gap.
Problem
When a MIDI device (e.g. a USB master keyboard) is plugged in / switched on after Wine (and a DAW such as Reaper) is already running, it is not detected. The DAW's MIDI device list and its "retry/refresh" do not pick it up; a previously-selected input shows as
<not found>. Only restarting Wine/DAW with the device already on makes it appear.Root cause (confirmed via
WINEDEBUG=+midi,+alsa,+winmmtrace)winealsaenumerates MIDI ports once at load time into the staticsrcs/destsarrays indlls/winealsa.drv/alsamidi.c. After that:SND_SEQ_EVENT_PORT_STARTwhen a new sequencer port appears.midiInGetNumDevs/midiInGetDevCaps.Net effect: a device not present at Wine start is invisible forever, no matter how often the DAW retries. Confirmed in a trace: at start winealsa enumerated 5 inputs (System, PipeWire×2, Midi Through, M4, nanoKEY2); after switching on an absent KM88 keyboard there was zero activity in the winealsa record thread — no announce event, no PORT_START. Reaper's "retry" re-queried
midiInGetDevCapsWfor devices 0–4 (the cached set) and never saw a device 5.Proposed fix — three layers
PORT_STARTPORT_START,port_adda brand-new device intosrcs/dests(not just re-attach an existing one)Layer 3 is the crux. Even with
srcs/destsupdated in winealsa, a DAW'smidiInGetDevCaps/midiInGetNumDevshits the winmm cache, not the driver — so the new device stays invisible until winmm re-enumerates. Solving only layers 1–2 (winealsa) is not enough; the DAW still won't see the new device.Related
Workaround (until fixed)
Switch the device on before starting Wine/DAW, so it is present in the one-time static enumeration.
Scope note
This issue concerns the winmm / winealsa (classic MIDI) path used by DAWs such as Reaper. Separately, some applications use the WinRT MIDI API (
Windows.Devices.Midi.MidiInPort), which Wine does not implement at all (dlls/haswindows.devices.bluetooth,.enumeration,.usb,windows.media.devices— but nowindows.devices.midi). That is a different, larger gap.