This affects Windows 95. It does not appear to have at least one of
these functions. This is convenient because the function
IDirectSound::CreateSoundBuffer() is failing in my tests and I wasn't
able to figure out what was going on. Simply failing context
initialization outright is an acceptable solution for now since
Windows 95 is such an uncommon target and it can always fall back to
WinMM which works.
It looks like CoInitializeEx() is not available on Windows 95. This
commit changes it so that if CoInitializeEx() cannot be found, such as
the case with Windows 95, it falls back to CoInitialize().
As of this commit, a crash still occurs when trying to initialize the
DirectSound backend. The WinMM backend works, however.
This change adds a fallback for when setting the format of the primary
buffer fails. I have observed this happening with floating point
formats so I've forced the use of integer PCM formats in the fallback
case. I've also restricted it to 44100 because when I tried 4800 on
my Windows 98 machine it resulted in incorrect output.
There are two things addressed with this commit:
* The use of CreateEventW() will fail at runtime on Windows 98. The
"A" version needs to be used instead.
* CreateThread() fails on Windows 98 if the last parameter is NULL.
This parameter takes a pointer to a DWORD which receives the
thread ID.
As of this commit, the DirectSound backend does not work on Windows 98.
The issue with this one was that the brute-force path was seeking back
to the start of the file rather than seeking to the start of the audio
data within the file.
The issue with this one is that it was possible for the asynchronous
loading process to override settings that were explicitly set via
ma_data_source_set_*(). The fix for this is to only set these on the
asynchronous side if the values in the resource manager's data source
config is not equal to defaults.
The issue here is that the code is trying to maintain the absolute
position of the loop point. The problem with this is that the absolute
position of the loop points could fall outside the new range which
would then result in no audio being read.
This becomes an issue because it would effect data sources even when
the loop point was never actually explicitly set. From these users
perspective, changing the range completely breaks their audio.
The new system simply resets the loop points. This works for users who
are using the default loop points (the majority of cases). For those
who are explicitly setting a loop point, they simply need to reset
their loop points after changing the range. This is not really an
issue, because loop points are relative to the range, which means a
change in the range would most likely warrant a change in the loop
point anyway.
Updating the noise type should not be supported. An oversight on my
part. Users should reinitialize a fresh `ma_noise` object instead.
This change simply returns an error and triggers an assert in debug
mode.
Public issue: https://github.com/mackron/miniaudio/issues/585
David Reid
Kaisei Sunaga
kaisei.sunaga
cdigit
SeanTolstoyevski
Patrick Stewart