[Bug 44548] New: Imperium GBR doesn' t reproduce audio associated with videos when native dsound.dll is loaded
https://bugs.winehq.org/show_bug.cgi?id=44548 Bug ID: 44548 Summary: Imperium GBR doesn't reproduce audio associated with videos when native dsound.dll is loaded Product: Wine Version: 3.2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dsound Assignee: wine-bugs(a)winehq.org Reporter: lorenzofer(a)live.it Distribution: --- Created attachment 60508 --> https://bugs.winehq.org/attachment.cgi?id=60508 WIne log with native dsound (and other directmusic dlls as builtin) Hi again Imperium GBR need the directmusic components to be able to play in-game (menu,game) audio (music, voices, UI effects). However the audio associated with the videos is reproduced correctly with all builtin. To be able to play in game sound the game need these dlls setted to native:dsound,dmime,dmsynth,dmusic,dswave However when setting dsound as native the audio of the videos (as the intro video) is not played anymore (the video component of the video is still played perfectly). To experience this issue you need to set as native dsound.dll only. If I also activate native quartz with native dsound the audio in videos is reproduced correctly, but the game will terminate before entering the main menu (Bug 44540) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44548 Lorenzo Ferrillo <lorenzofer(a)live.it> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum(a)codeweavers.com -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44548 --- Comment #1 from Lorenzo Ferrillo <lorenzofer(a)live.it> --- Andrew sorry to bother you. I putted you into the CC list becouse you were very active on others dsound related bugs, and may give some insight of what is going terribily wrong here -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44548 --- Comment #2 from Andrew Eikum <aeikum(a)codeweavers.com> --- Games that use directmusic must use the native dsound and directmusic components. Something like "winetricks directmusic" should be enough. Can you try making a clean prefix, install directmusic with winetricks, then install the game? If you are still having a problem, please attach a log in that state with the channels from https://wiki.winehq.org/Sound . Thanks. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44548 --- Comment #3 from Lorenzo Ferrillo <lorenzofer(a)live.it> --- I already have native directmusic and dsound. The bug I'm experiencing is that audio in videos (not the in game music and sound) doesn't play anymore from the moment I activate native dsound.dll (it is working properly with builtin dsound). The bug is experienced with just dsound native acivated, using all directmusic dlls as native (except native quartz per bug 44540) does make the audio in game work. But the videos are still silent. I noticed that if I activate all directmusic native dlls (again except quartz), but leaving dsound as builtin, the audio in video works as supposed to do (in game audio doesn't obviosuly works, but that's not the point here). If I activate native quartz the audio on the video works, but the game terminate before entering into main menu. The log were generated only with native dsound as it is the only dll needed to trigger this bug. (Note I'm expecting in this case that in game audio doesn't work) Imperium GBR is installed in a clean wineprefix, and it is installed after installing dsound and directmusic with winetricks. I'm using ArchLinux x64, game is installed in a 32 wineprefix. I will make a log with that debug channels asap. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44548 --- Comment #4 from Lorenzo Ferrillo <lorenzofer(a)live.it> --- Created attachment 60528 --> https://bugs.winehq.org/attachment.cgi?id=60528 Log with requested trace Attached a log with the channel in the Sound page. Using all directmusic native dlls(except amstream and quartz), using dsound native. If I activate native amstream, videos will not play anymore at all (probably another bug). I will take a similar log with quartz native in the quartz related bug report -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44548 --- Comment #5 from Lorenzo Ferrillo <lorenzofer(a)live.it> --- Hi. The bug is still present as 3.20 These days I had the possibility to look a bit more. Quartz is trying to request a secondary buffer in DSoundRender_CompleteConnect, with the format WAVE_FORMAT_EXTENSIBLE and KSDATAFORMAT_SUBTYPE_IEEE_FLOAT subtype, with 32 wBitsPerSample (the format is created elsewhere). Now the wine dsound.dll gladly accept this format, in the IDirectSound8_CreateSoundBuffer call. However native dsound.dll (installed by winetricks) refuse the format with a DSERR_BADFORMAT error. I tryed to reproduce as a small testcase and it showed that native dsound.dll refuse: WAVE_FORMAT_EXTENSIBLE with KSDATAFORMAT_SUBTYPE_IEEE_FLOAT; WAVE_FORMAT_EXTENSIBLE with KSDATAFORMAT_SUBTYPE_PCM with wBitsPerSample as 32; WAVE_FORMAT_IEEE_FLOAT with wBitsPerSample as 32 (I didn't try different values for wBitsPerSample) All these formats are instead accepted by wine dsound.dll, and by Windows machines (I submitted the testcase to the testbot). Testbot result (allowing to download a test executable and the testcase patch): https://testbot.winehq.org/JobDetails.pl?Key=44482 I don't know how much these will stay online. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44548 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair(a)hotmail.com --- Comment #6 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- (In reply to Lorenzo Ferrillo from comment #5)
Testbot result (allowing to download a test executable and the testcase patch): https://testbot.winehq.org/JobDetails.pl?Key=44482 I don't know how much these will stay online.
Can you please attached the patch to this bug? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44548 --- Comment #7 from Lorenzo Ferrillo <lorenzofer(a)live.it> --- Created attachment 64577 --> https://bugs.winehq.org/attachment.cgi?id=64577 patch for test Sorry, I thought to have lost the patch. This is a quartz patch that add some DsoundRender test. I should probably rebase it to dsound but I don't have much time. Tests succeeed on windows machines, and on wine with builtin dsound, but fail with native dosund on wine -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44548 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44548 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #64577|0 |1 is obsolete| | --- Comment #8 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Created attachment 64605 --> https://bugs.winehq.org/attachment.cgi?id=64605 Updated Patch Here is a updated patch. (besides I think the tests belong in dsound). 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? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44548 --- Comment #9 from Lorenzo Ferrillo <lorenzofer(a)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.
https://bugs.winehq.org/show_bug.cgi?id=44548 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #10 from joaopa <jeremielapuree(a)yahoo.fr> --- Shoudn't this bug be closed as INVALID since it is about a use of native dll? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44548 --- Comment #11 from Lorenzo Ferrillo <lorenzofer(a)live.it> --- (In reply to joaopa from comment #10)
Shoudn't this bug be closed as INVALID since it is about a use of native dll?
This bug happen when using a know workaround (directmusic + dsound) that is otherwise know to be a good trick to have audio in directmusic games. I'm not against closing the bug, however I think that a warning in case should be present in the wiki (as it is where the workaround is suggested). Also I clearly remember to work sucessfully some years ago, I don't know if the the change happened in wine or in winetricks that broke this. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=44548 --- Comment #12 from Lorenzo Ferrillo <lorenzofer@live.it> --- Hi, I retested this after a while, and turn out the issue doesn't seem to be a problem anymore on wine and wine-staging 11 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=44548 Lorenzo Ferrillo <lorenzofer@live.it> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #13 from Lorenzo Ferrillo <lorenzofer@live.it> --- unsure when the issue got actually resolved, but last version tried with the bug was before wine 8... Wine 11 works fully -- 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.
http://bugs.winehq.org/show_bug.cgi?id=44548 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #14 from Alexandre Julliard <julliard@winehq.org> --- Closing bugs fixed in 11.2. -- 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.
participants (3)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla -
WineHQ Bugzilla