https://bugs.winehq.org/show_bug.cgi?id=44548
--- Comment #9 from Lorenzo Ferrillo lorenzofer@live.it --- (In reply to Alistair Leslie-Hughes from comment #8)
I've tried running these tests locally (wine) and on the testbot without a single test failing.
Can you check that this is still an issue?
Sorry for the radio silence.
The problem is still here, but it's not visible in the testbot. I will reexplain, as maybe I wasn't much clear in the previous posts. Sorry English isn't my mother tongue.
Now this bug is anomalous, and as native DLLs are involved it could be classified as invalid by wine policy, but as DirectMusic is involved maybe you will make an exception.
GBR is an old game, created in an era when using DirectMusic was paramount.
As wine's DirectMusic is badly incomplete, to have in-game sound we have to install some native DirectMusic dlls, in particular: dmime,dmsynth,dmusic,dswave
But these dlls aren't enough. DirectMusic component dmime.dll use a private internal interface of DirectSound, that of course doesn't exist at all in wine's Dsound.dll So I have to install native dsound.dll as well. And it work the in-game audio now fully works (in-game music also needed dsdmo.dll before it was added in staging, but that's just for reference).
But now arise a problem with the audio reproduction of the videos that ship with the game, that now stopped workging completly. (For example the initial video, or the videos of the campaigns)
Summary (assuming native dmime,dmsynth,dmusic,dswave are installed and setted as native override): Builtin dsound.dll | native dsound.dll in game audio NO | YES Video audio YES | NO
This bug is only for the impossibility to reproduce video's audio with native dsound.dll. Note: just using native dsound.dll override trigger this bug, no need to have DirectMusic.
Ok so what's happening, here?
the game is using quartz.dll MPEG decoder, and for the audio part is requesting a secondary buffer in DSoundRender_CompleteConnect to hold sound data, with format WAVE_FORMAT_EXTENSIBLE and KSDATAFORMAT_SUBTYPE_IEEE_FLOAT subtype, with 32 wBitsPerSample. It's done by calling IDirectSound8_CreateSoundBuffer and passing the specified format, and expectingit to succeed.
Now builtin dsound.dll gladly accept to create the buffer with the specified format,and the video audio works.
But then native dsound.dll instead refuse the buffer with a DSERR_BADFORMAT error.
I wanted to check how the kind of stuffs worked on windows, so I wrote that tests mimiking quartz DsoundRender_CompleteConnect, with various waveformats (all valid according to microsoft specifications), in particular these formats were: WAVE_FORMAT_PCM WAVE_FORMAT_IEEE_FLOAT WAVE_FORMAT_EXTENSIBLE with KSDATAFORMAT_SUBTYPE_PCM WAVE_FORMAT_EXTENSIBLE with KSDATAFORMAT_SUBTYPE_IEEE_FLOAT
And then sent the patch to the testbot. Unsurprisingly got all success on all Windows VMs. Also all 4 formats works with dsound builtin dll.
When testing in local with the builtin dll all tests worked as expected, but when I started the test with native dsound.dll I started getting failures. WAVE_FORMAT_IEEE_FLOAT and WAVE_FORMAT_EXTENSIBLE with KSDATAFORMAT_SUBTYPE_IEEE_FLOAT were consistently failing to create the requested buffer, while WAVE_FORMAT_PCM and WAVE_FORMAT_EXTENSIBLE with KSDATAFORMAT_SUBTYPE_PCM were consistently succeeded.
Then I tryed to make a test with little different buffer: I took the WAVE_FORMAT_EXTENSIBLE with KSDATAFORMAT_SUBTYPE_PCM format, but instead of keeping the wBitsPerSample to 16, setted wBitsPerSample to 32. Now this is completly valid according to the specification, and in fact all windows machines were reporting success, as builtin dsound as well. But the native dsound on wine was instead reporting failure. So it seems like a general problem for 32bit WAVEFORMATS, instead of a FLOAT waveformat problem.
I thought that maybe native dsound.dll is checking in an another subsystem for which formats are valid, but I couldn't find anything relevant.
Putting quartz.dll native is not a workaround. (actually quartz native seems to request the exact same format).
The most disturbing things about this bug is that I remember this game to fully work with directmusic and native dsound when I started using wine around wine 2.x or even 1.7.x