MikMod CLI player is unresponsive, playback lags noticeably behind display.

[AliceLR]

I haven't tested the MikMod CLI player very much in Linux but in Windows 10/MSYS2, I've encountered the following bugs consistently:

• When using OSS, the player often takes a second or more to respond to Q or Ctrl+C presses. This isn't an issue with WinMM so it might be a problem with MSYS2 OSS.
• The player display is usually a second or two ahead of playback (both OSS and WinMM).
• When using the WinMM driver, sometimes the end of the track will be cut off (presumably because the player is ahead of the audio playback). This doesn't happen when using the OSS driver.

These bugs can make testing annoying sometimes. I don't know the cause of these but I can look into them further.

[AliceLR]

The WinMM audio lag and end of track being cut off issues both disappear when I change the number of buffers in the WinMM driver to 2 instead of 6...

[sezero]

I honestly don't know how and can't believe that MSYS builds catch OSS as an enabled driver. So, I will ignore any MSYS+OSS issues. I can not test at the moment but OSS on Linux has been behaving very well. If PR

30 fixes everything else, this can be closed with that.

[AliceLR]

I honestly don't know how and can't believe that MSYS builds catch OSS as an enabled driver. So, I will ignore any MSYS+OSS issues.

The header for it is provided by the MSYS2 core packages but I'm not sure which library handles it or how. Since MSYS2 is trying to be most of a Linux environment it makes sense it'd have bindings for OSS.

$ pkgfile /usr/include/sys/soundcard.h
msys/msys2-runtime-devel

I don't know what exactly configure is deriving $host_os from but if it's uname -o the result is Msys, which isn't detected in configure.ac. The configure script also did not detect WinMM until I manually edited out whatever was disabling it. Doing anything about that seems out of scope for this issue but I think 1) detection of MSYS2 should be fixed (if it's broken) to at the very least allow the WinMM driver, 2) I could go either way re: enabling or disabling OSS; it's not broken outright but it shouldn't be the default driver with this setup.

I can not test at the moment but OSS on Linux has been behaving very well. If PR #30 fixes everything else, this can be closed with that.

I think that would be OK.

[sezero]

I can not test at the moment but OSS on Linux has been behaving very well. If PR #30 fixes everything else, this can be closed with that.

I think that would be OK.

OK then, closing.

[sezero]

I honestly don't know how and can't believe that MSYS builds catch OSS as an enabled driver. So, I will ignore any MSYS+OSS issues.

The header for it is provided by the MSYS2 core packages but I'm not sure which library handles it or how. Since MSYS2 is trying to be most of a Linux environment it makes sense it'd have bindings for OSS.

$ pkgfile /usr/include/sys/soundcard.h
msys/msys2-runtime-devel

I don't know what exactly configure is deriving $host_os from but if it's uname -o the result is Msys, which isn't detected in configure.ac. The configure script also did not detect WinMM until I manually edited out whatever was disabling it. Doing anything about that seems out of scope for this issue but I think 1) detection of MSYS2 should be fixed (if it's broken) to at the very least allow the WinMM driver, 2) I could go either way re: enabling or disabling OSS; it's not broken outright but it shouldn't be the default driver with this setup.

I don't know how to fix detecting msys through configury (I don't know whether I want to), but can we not add a win32/Makefile.msys for that? (See win32/Makefile.mingw for a good starting point.)

[AliceLR]

I don't know how to fix detecting msys through configury (I don't know whether I want to)

Turns out the new $host_os for MSYS2 is just msys, so it's trivial to detect (and configure.ac was already detecting mingw* and cygwin*, so there's precedent). Aside from not checking for that, the only other issue I found was my environment (and apparently others) require windows.h to be included explicitly before dsound.h (both in AC_CHECK_HEADERS and in drv_ds.c).

The only things the MikMod player configure script checks for mingw/cygwin for are curses and pthread support, both of which seem to be well-supported by modern MSYS, so I didn't bother adding checks there.

but can we not add a win32/Makefile.msys for that? (See win32/Makefile.mingw for a good starting point.)

The Makefile.mingw makefile works as-is in MSYS2, so I don't think a new one would be necessary. I only realized it existed after I already had working builds with autotools so I never actually tried it before now...