[BUG/PATCHES] Linux ALSA RawMidi buffer overflow with Windows 95

Post new patches here!
Post Reply
flk92
Posts: 2
Joined: Mon 15 Feb, 2021 8:06 pm

[BUG/PATCHES] Linux ALSA RawMidi buffer overflow with Windows 95

Post by flk92 »

Under Linux, v17 will either crash (in release mode) or have General MIDI stop working (in debug mode) after stopping MIDI playback using the default player under Windows 95.
This is due to a buffer overflow on src/midi_alsa.c while parsing the messages. It gets stuck in SysEx mode after corrupting the boolean that controls this state.

To fix this I have written 2 patches:

Patch A is the simple fix, it just removes the code that keeps track of the MIDI state before sending out to ALSA and replaces it with just the call that outputs the value.
0001-Fix-buffer-overflow-on-ALSA-MIDI-output.patch
Patch A, just the RawMidi fix.
(2.88 KiB) Downloaded 342 times
This is OK since (unless I'm misunderstanding) ALSA keeps its own buffers for it anyway.
I've also written another version that keeps track of the MIDI messages, like the original, and couldn't spot any differences in performance, regardless of what MIDI device I used.

Patch B adds support for the more convenient ALSA sequencer MIDI interface, in addition to the fix from A.
0002-Introduce-the-MIDI-ALSA-sequencer-interface.patch
Patch B, the ALSA sequencer implementation. Requires Patch A applied.
(13.71 KiB) Downloaded 327 times
This is the same interface as used by most other software in Linux.
It's more convenient since it doesn't require the more complicated setup PCem currently depends on of either having a hardware MIDI device connected, or loading a kernel extension that provides virtual RawMidi devices.
In the case of the virtual RawMidi devices, it's still necessary to route the MIDI messages through the ALSA sequencer's interface (such as by using aconnect(1)), so using the sequencer directly just makes more sense.

I have tested it with both FluidSynth and a USB MIDI synthesizer and I couldn't spot any differences between the sequencer and RawMidi.

It shouldn't break anybody's config since the first entries are still the RawMidi devices, but I don't think anybody has working configurations in the first place given that this bug exists, and that the configuration keeps an index into a list of detected devices, which doesn't make much sense for ALSA since it can change at any time and is best served by a string representing the name of the RawMidi device as set up in ALSA configuration files, or by the client id:port combo for the sequencer.
I understand that the limitation on the configuration is probably due to how MIDI devices are enumerated on Windows, but I haven't invested time in changing the configuration files to adapt for Linux users, so the current index-based approach will have to do for now.

If you do not have any hardware MIDI devices, index 0 will always be the very convenient client 14, "Midi Through", always present by default.
It's convenient because you can just start FluidSynth at any time and wire it to 14:0, which will in turn route the MIDI messages from PCem (or any other software connected to 14:0, such as Wine or DOSBox) into it:

Code: Select all

# Example: FluidSynth is currently running in the background, with the client ID 128
aconnect 14:0 128:0
# Start any software that connects to 14:0 for MIDI and it'll just work now!
You can also do that to route 14:0 into hardware MIDI devices, or both HW and SW simultaneously, or whatever other crazy configuration you need.
Use aconnect -l to list available clients.

I don't know what was the reason behind implementing RawMidi originally, which is why I haven't removed support for it.
If you know why, let me know. I'm curious!

(small note: I've read the guidelines to submitting patches and it mentions a Mercurial repository, which I couldn't find. These patches go against the GitHub mirror.)
shermanp
Posts: 175
Joined: Sat 18 Feb, 2017 2:09 am

Re: [BUG/PATCHES] Linux ALSA RawMidi buffer overflow with Windows 95

Post by shermanp »

flk92 wrote: Thu 18 Feb, 2021 7:53 pm (small note: I've read the guidelines to submitting patches and it mentions a Mercurial repository, which I couldn't find. These patches go against the GitHub mirror.)
Sarah moved the repository to GitHub when Bitbucket decided to drop mercurial support and offered no migration tools to convert mercurial repositories to Git repositories.

So yeah, as far as I know, that GitHub repo is the primary one.
Post Reply