[Bug 44548] Imperium GBR doesn't reproduce audio associated with videos when native dsound.dll is loaded

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=44548

--- Comment #9 from Lorenzo Ferrillo <lorenzofer at 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

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.