[Bug 30836] New: Total Overdose: choppy audio playback with Diesel Power 3D sound system
http://bugs.winehq.org/show_bug.cgi?id=30836
Bug #: 30836 Summary: Total Overdose: choppy audio playback with Diesel Power 3D sound system Product: Wine Version: 1.5.5 Platform: x86 URL: http://www.gamershell.com/download_10831.shtml OS/Version: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: directx-dsound AssignedTo: wine-bugs@winehq.org ReportedBy: gyebro69@gmail.com CC: aeikum@codeweavers.com Classification: Unclassified Regression SHA1: 1cc9ecb558e09a94e1b92331ca132634e8dac8f9
Created attachment 40385 --> http://bugs.winehq.org/attachment.cgi?id=40385 7zipped +tid,+mmdevapi,+winmm,+driver,+midi,+dsound,+dmusic,+mci,+alsa log (uncompressed 5.3 MB)
Music and speech are skipping in Total Overdose when audio engine used by the game is set to 'Auto' or 'Diesel Power 3D' in the options menu. The demo version of the game doesn't let change audio systems, it always uses Diesel Power 3d, so the problem can be reproduced with the demo version as well. After installation start the demo with TOD.exe. During the intro videos you can observe that music playback is very choppy, skipping heavily.
This is a regression from Wine 1.5.5, caused by
1cc9ecb558e09a94e1b92331ca132634e8dac8f9 is the first bad commit commit 1cc9ecb558e09a94e1b92331ca132634e8dac8f9 Author: Andrew Eikum aeikum@codeweavers.com Date: Tue May 15 14:41:24 2012 -0500
dsound: Don't use IAudioClock::GetPosition to determine buffer fullness.
:040000 040000 6e93eb30269b9505a4196f15b1e81d2674d3dc01 a52ed8250ea70d34c40d382397c806ce9e06aba0 M dlls
Reverting the patch on wine-1.5.5-131-gbdd4294 fixes the problem for me. Should be noted that there was a problem with audio in TOD, but that was fixed in 1.5.4 (bug #27603).
Fedora 17 x86 Alsa 1.0.25 Pulseaudio is not running Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2)
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #1 from Andrew Eikum aeikum@codeweavers.com 2012-06-14 10:00:43 CDT --- Reverting that commit doesn't fix it for me. The application seems badly behaved. It locks the entire buffer for writing when it needs to write new data. Still looking into what's going on to cause the audio skipping (at a guess, maybe we should update the write/play positions somehow after Unlock in this case?).
http://bugs.winehq.org/show_bug.cgi?id=30836
Ruslan b7.10110111@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |b7.10110111@gmail.com
--- Comment #2 from Ruslan b7.10110111@gmail.com 2012-06-21 09:21:32 CDT --- I confirm that this commit leads to sound artifacts. Namely, in GTAIV sound clicks at least in the intro videos. Reverting the commit removes the clicks.
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #3 from Andrew Eikum aeikum@codeweavers.com 2012-06-22 10:44:45 CDT --- Ruslan: Could you gather a log with the channels from http://wiki.winehq.org/Sound and attach it here, please?
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #4 from Ruslan b7.10110111@gmail.com 2012-06-22 13:32:53 CDT --- Created attachment 40655 --> http://bugs.winehq.org/attachment.cgi?id=40655 GTAIV sound log
Here it is
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #5 from Ruslan b7.10110111@gmail.com 2012-07-18 06:19:07 CDT --- Still present in 1.5.9
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #6 from GyB gyebro69@gmail.com 2012-09-24 12:58:49 CDT --- Zaxxon is a small, freeware remake of a classic shooter. The game runs without audio after commit 1cc9ecb558e09a94e1b92331ca132634e8dac8f9 dsound: Don't use IAudioClock::GetPosition to determine buffer fullness.
http://www.classic-retro-games.com/Zaxxon_70.html
wine-1.5.13-232-gc0d2029
http://bugs.winehq.org/show_bug.cgi?id=30836
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mstefani@redhat.com
--- Comment #7 from Michael Stefaniuc mstefani@redhat.com 2012-10-08 17:58:18 CDT --- GyB, I have tested Zaxxon and the sound works for me with or without commit 1cc9ecb558e09a94e1b92331ca132634e8dac8f9. Though the game deadlocks pretty fast; again with or without the offending commit. But that might be my old F14 / r600g as the X server is messed up (cannot start Zaxxon a second time) and I have to restart it.
Fedora 14 x86_64 Alsa 1.0.24 Pulseaudio is running Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #8 from GyB gyebro69@gmail.com 2012-10-08 21:41:32 CDT --- Created attachment 42033 --> http://bugs.winehq.org/attachment.cgi?id=42033 Zaxxon sound log
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #9 from Andrew Eikum aeikum@codeweavers.com 2012-10-09 15:31:11 CDT --- Created attachment 42053 --> http://bugs.winehq.org/attachment.cgi?id=42053 dsound: Don't exit early in mixer thread
This patch fixes the Zaxxon problem, but doesn't seem to fix the Total Overdose choppiness.
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #10 from Andrew Eikum aeikum@codeweavers.com 2012-10-10 13:29:56 CDT --- I haven't figured out TOD's algorithm for writing more audio data. It holds the _Lock()ed buffer and polls IDirectSoundBuffer::GetCurrentPosition() rapidly. It seems to trigger an _Unlock()-_Lock() cycle when GetCurrentPosition's PlayCursor parameter changes. But if you hack PlayCursor to never change, then it does those cycles anyway, often in rapid succession.
At some level, there are two timers that TOD depends on being in sync. One is the timer that controls GetCurrentPosition()'s PlayCursor, and the other is its own internal clock. When they get out of sync, TOD seems to assume that the entire buffer has been played and proceeds to write the entire next buffer, so you get the choppy, too-fast audio that this bug describes.
The patch that caused the regression changed how dsound depends on the audio driver's timing. It sometimes takes more than a period for the ALSA driver to update its IAudioClient::GetCurrentPadding(). That means the PlayCursor now takes too long to change, and falls out of sync with how TOD expects it to be have, so it assumes the whole buffer has been played, and skips ahead in its audio.
I'm working on changes to how winealsa times its writes to ALSA to play more nicely with a PulseAudio backend. I tested TOD with my preliminary patch, and it actually fixes the timing issue, causing TOD to work correctly again. If you want to test an early version of the patch, you can find it on Bug 28622, "winealsa.drv: Feed data at a fixed rate".
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #11 from GyB gyebro69@gmail.com 2012-10-13 12:49:20 CDT --- Andrew, the patch in bug #28622 indeed fixes the audio issue in Total Overdose.
Alsa 1.0.26 on Fedora 17 Pulseaudio is not running Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2)
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #12 from GyB gyebro69@gmail.com 2012-10-16 04:04:36 CDT --- Fahrenheit (also known as Indigo Prophecy) is also affected by this commit, but in a slightly different way: the game crashes during the intro video when I start a new game. The crash always occurs at the same point (nearly at 1:40 mins). The patch in bug #28622 fixes this problem too. 'winetricks dsound' also works around the crash in Fahrenheit.
http://bugs.winehq.org/show_bug.cgi?id=30836
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #13 from Jörg Höhle hoehle@users.sourceforge.net 2012-10-24 16:27:16 CDT --- Andrew, seeing this bug I understand why you'd like to get that other patch into Wine. Yet it's unclear to me what exactly makes it work: your patch does 2 things, the rate limiting and some changes to ALSA buffer sizes and periods. I mean, it could work by side-effect rather than due to actual rate limiting.
Your analysis appears very plausible.
It sometimes takes more than a period for the ALSA driver to update its IAudioClient::GetCurrentPadding().
"sometimes" because of jitter or why? Or because the ALSA buffer may be filled with the effect that mmdevapi:GetCurrentPadding may not decrease for 2-3 mmdevapi periods or at least one ALSA period (which could be as much as 100ms)? In that case, we should conclude that it's a bug for mmdevapi:GetCurrentPadding not to decrease as regularly as native's. My point is that there can be solutions to this independently of rate-limiting, e.g. I imagine a driver that decrements padding exactly once per event by one period worth of frames and adapts its event rate to +/- 20% actual drain by the underlying ALSA driver.
DSound should be somewhat independent on mmdevapi. All apps named here do not see mmdevapi directly rather than DSound. So it's clearly a bug of DSound's GetCurrentPosition not to change as regularly as the "Direct HW ping pong buffer" abstraction would suggest. That might be tackled independently on mmdevapi.
The (unsurprising) lesson is: it's not enough to satisfy the API. The apps very much depend on comparable dynamic behaviour.
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #14 from Ruslan b7.10110111@gmail.com 2012-12-27 14:31:09 CST --- In GTASA this bug is still present as of wine-1.5.20-57-gdabde6a. But performance is a bit better than a month or two ago (2-3 FPS vs 0.5-1 FPS). But it still is an order of magnitude slower than before regression.
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #15 from Andrew Eikum aeikum@codeweavers.com 2012-12-27 14:52:25 CST --- Ruslan, could you try building with the patch in Bug 28622? GyB reports that it fixes this issue for him.
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #16 from GyB gyebro69@gmail.com 2012-12-27 15:07:12 CST --- (In reply to comment #14)
In GTASA this bug is still present as of wine-1.5.20-57-gdabde6a. But performance is a bit better than a month or two ago (2-3 FPS vs 0.5-1 FPS). But it still is an order of magnitude slower than before regression.
Maybe you confused this bug with bug #30639? Wasn't it GTA IV that suffered from audio artefacts as per comment #2 ? It was GTA:SA that had the performance loss as per http://bugs.winehq.org/show_bug.cgi?id=30639#c22
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #17 from Ruslan b7.10110111@gmail.com 2012-12-27 15:12:42 CST --- (In reply to comment #16)
Maybe you confused this bug with bug #30639? Wasn't it GTA IV that suffered from audio artefacts as per comment #2 ? It was GTA:SA that had the performance loss as per http://bugs.winehq.org/show_bug.cgi?id=30639#c22
Oops, you're right. Posted in wrong bug, sorry.
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #18 from Ruslan b7.10110111@gmail.com 2013-01-10 08:20:12 CST --- The clicks in GTAIV are still present as of wine-1.5.21-109-g136b738.
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #19 from Ruslan Kabatsayev b7.10110111@gmail.com 2013-04-27 02:48:48 CDT --- Clicks in GTAIV still present in wine-1.5.29
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #20 from Ruslan Kabatsayev b7.10110111@gmail.com 2013-06-11 10:42:05 CDT --- Clicks in GTAIV still present in wine-1.6-rc1-18-gb82a5ab
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #21 from Ruslan Kabatsayev b7.10110111@gmail.com 2013-10-28 03:59:23 CDT --- Clicks in GTAIV still present in wine-1.7.5
http://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #22 from Ruslan Kabatsayev b7.10110111@gmail.com --- Clicks in GTAIV still present in wine-1.7.14-126-g2bb1059
https://bugs.winehq.org/show_bug.cgi?id=30836
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #23 from Andrew Eikum aeikum@codeweavers.com --- I think the original Total Overdose issue is fixed by
commit d301254e72f018c3e04272115e20ffc70ffcbc12 Author: Andrew Eikum aeikum@codeweavers.com Date: Wed Dec 17 09:28:13 2014 -0600
mmdevapi: More accurately track device position.
https://bugs.winehq.org/show_bug.cgi?id=30836
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |d301254e72f018c3e04272115e2 | |0ffc70ffcbc12 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #24 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Andrew Eikum from comment #23)
I think the original Total Overdose issue is fixed by
commit d301254e72f018c3e04272115e20ffc70ffcbc12 Author: Andrew Eikum aeikum@codeweavers.com Date: Wed Dec 17 09:28:13 2014 -0600
mmdevapi: More accurately track device position.
Yes indeed, it's fixed in wine-1.7.33-40-gca51e11, thank you.
https://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #25 from Ruslan Kabatsayev b7.10110111@gmail.com --- (In reply to Andrew Eikum from comment #23) Thanks, it also fixes clicks in GTAIV.
https://bugs.winehq.org/show_bug.cgi?id=30836
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #26 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.34.
https://bugs.winehq.org/show_bug.cgi?id=30836
hash HASH.DuOrden@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |HASH.DuOrden@gmail.com
--- Comment #27 from hash HASH.DuOrden@gmail.com --- Created attachment 50994 --> https://bugs.winehq.org/attachment.cgi?id=50994 log generated as it suggested in http://wiki.winehq.org/Sound.
I got here after searching for commit d301254e72f018c3e04272115e20ffc70ffcbc12 as a result of regression testing, after this commit I get crazy clicks in Blizzard's "Heroes of the Storm" and "Diablo 3", and also some slightly annoying clicking in "World of Tanks".
I am on Gentoo x86-64 multilib, OSSv4. It is enough to revert wineoss.drv/mmdevdrv.c part of this commit to "fix" this regression.
In "Heroes of the Storm" and "Diablo 3" there is a settings in "Option -> Sound -> Quality -> Sound Quality:". But only in "Heroes of the Storm" it helps if I set this to "Low", then the clickering is reduced to once a minute or so. But in "Diablo 3" this setting do not change anything. In "World of Tanks" this only noticeable in hangar and when I view destroyed tank during a battle.
I attached log generated as it suggested in http://wiki.winehq.org/Sound.
And here is regression final output: 301254e72f018c3e04272115e20ffc70ffcbc12 is the first bad commit commit d301254e72f018c3e04272115e20ffc70ffcbc12 Author: Andrew Eikum aeikum@codeweavers.com Date: Wed Dec 17 09:28:13 2014 -0600
mmdevapi: More accurately track device position.
:040000 040000 d2d3ae33a3b768fb03324d6c038bbcd79d9742d0 ec4be94754d577889ba445bd40dd097c9f2043f7 M dlls
https://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #28 from hash HASH.DuOrden@gmail.com --- Oh and one thing that is the reason I posted it here, in instructions for regression testing it says that I should first search for a bug in which the culprit commit is mentioned and post there and only if I don't find any such bugs I should create a new one, so here is a question, should this regression be solved here or should I create a new bug?
https://bugs.winehq.org/show_bug.cgi?id=30836
--- Comment #29 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to hash from comment #28)
Oh and one thing that is the reason I posted it here, in instructions for regression testing it says that I should first search for a bug in which the culprit commit is mentioned and post there and only if I don't find any such bugs I should create a new one, so here is a question, should this regression be solved here or should I create a new bug?
Please open a new bug report for the problem you're experiencing because this bug report was closed as fixed. If there is a demo available to reproduce the problem please add it to the new bug report.
-
wine-bugs＠winehq.org