Absolutely legendary work btw getting Mixere and Audiere to actually compile on Windows in 2022! I've tried several times to get the poikilos fork of Audiere running but always ran into problems outside my knowledge to fix. With this as a base, I've been able bounce off the VS2022 project file you've provided here to get a modern-compiled Audiere working for my GMALP wrapper project and get 64-bit support going for use under Game Maker Studio 2's x64 runtime.

In the process I discovered an issue which Mixere also suffers from: delayed playback. Takes about a second to start playing, about a second to stop. As long as the build environment only has HAS_WINMM enabled, Audiere only ever finds the poor WinMM audio device and picks that to initialise with, which performs about as well as molasses. Getting it to compile with HAS_DSOUND leads to a few other minor issues upstream but is easily fixable and will get you a DirectSound-supporting Audiere with instant playback. If you're interested in getting that going, I can provide a diff in a few days with my changes to the project file as well as the very few bugfixes I did upstream.

Sidenote: Unfortunately having the DirectSound device available to Audiere doesn't seem to solve Mixere's inconsistent looping, that may be a buffer issue or something possibly relying on some of Audiere's broken LoopPointSourcePtr functions. My workaround for the broken getPosition function in GMALP was to manually calculate the amount of samples being processed based on a given time multiplier provided by the program that loads the DLL in the first place, which is probably a very crude means to an end.

Mixere still uses the system's local code page. This prevents uses from opening audio files with names that contain graphemes that cannot be represented in their code page (for example, files with CJK graphemes on an English copy of Windows).

Mixere only builds in 32-bit mode, and even so with many implicate casts between differing integer types. These casts should be cleaned up, parameters and returns adjusted, and made to support building in both 32- and 64-bits.

Mixere relies heavily on the audio file and playback library Audiere. Like Mixere, Audiere hasn't had a release in over a decade, which is somewhat concerning in the scary world of 2021's internet. We also currently only have 32-bit versions of audiere.dll, which will cause problems for #2.

Per your request and per the sidenote in the last issue topic I created, it has been my observation that Mixere seems to have trouble with consistently looping tracks using a selected range in the position column.

Very easy to replicate, just load a sound file into any slot, select a range, set looping on, watch it stutter its way from the beginning or from the selected point over and over again.

I suspect this is in part due to some kind of breakage in Audiere's LoopPointSourcePtr class getPosition() code. I found in scanning what it was providing compared to the default Audiere source class equivalent function that it seems to be rather delayed in returning sample positions when testing Audiere for my GMALP project, and there's suggestions the previous developer knew of this in Mixere's Audio.cpp:

loop source position is 1 second in the future relative to sound
source position; we can partially fix it by rotating loop source
position backwards 1 second, but we'll still get bogus positions
when entering a loop for the first time.

My solution for this function's problematic behaviour in GMALP was rather than use the function at all, instead manually calculate where the sample position should've changed to given the track playback frequency, start/end positions, and the time between update calls (which may or may not apply in Mixere's case since GMALP was designed as a wrapper for Audiere calls to Game Maker, which has no asynchronous DLL call support per se). Even if this ends up being the way forward for Mixere though, I have to wonder why Audiere didn't just do that within the function in the first place.