Mp3dec asi ошибка

Hello there.

I’ve been playing the GOG.com version of Heroes of Might & Magic III Complete on a few recent Wine versions. It always works fine except for the issue in bug #14055, i.e. it eventually crashes in mp3dec.asi if played with the music on (sample backtrace). Many AppDB entries for the various HOMM3 versions have everything relevant working flawlessly, especially the GOG.com version’s, and even when there are sound problems, #14055 isn’t involved. This makes me wonder: Is the aforementioned music crash no longer happening for most people on modern Wine versions, and if so, why? Is there perhaps some reliable workaround I haven’t found? And finally, could there be something wrong with my system?

My setup is as follows:
— Intel Celeron 334 MHz (32-bit, from 1998)
— GeForce 2 MX with the proprietary nvidia-glx 96.43.18 drivers
— Debian Squeeze (6.0.5) with backported Linux 2.6.39 kernel

I’ve tried Wine 1.4.0 and 1.5.16 from the Squeeze-compatible Mepis 8.5 repos (as described here) in Windows 98 mode, and they seem to work as they should with all sorts of programs. The workarounds (for Windows or Linux) I’ve found either don’t work or don’t help; most problems involving mp3dec.asi seem to have been solved by setting the process affinity with schedtool on a multi-core system, but mine’s single-core.

While I certainly can play the game without music, I’d be very happy to know how this crashing issue seems to have been eliminated.

Seems the music crash isn’t my only problem. While re-trying the exe patcher sound fix, the patched Heroes3.exe once crashed with a segfault in __wine_emulate_instruction following an exception in ntdll (backtrace). Unfortunately I wasn’t recording terminal output at this point, so I got no further info, and I haven’t been able to reproduce the crash. I expect it’s nothing to do with the sound fix itself since that just changes a few sound setup parameters and makes no practical difference, and at least it shouldn’t be bug #20380 as that’s supposed to have been fixed by Linux 2.6.34. If this thing is indeed independent of the music issue, I might in time be able to provoke it separately when playing without music.

Afterwards, I have been following the terminal output. This is what a typical session produces until the mp3dec.asi crash:

fixme:win:EnumDisplayDevicesW ((null),0,0x33f800,0x00000000), stub!
err:d3d:context_choose_pixel_format Can't find a suitable iPixelFormat
fixme:d3d:swapchain_init Add OpenGL context recreation support to context_validate_onscreen_formats
err:d3d:context_choose_pixel_format Can't find a suitable iPixelFormat
err:ole:CoGetClassObject class {5959df60-2911-11d1-b049-0020af30269a} not registered
err:ole:CoGetClassObject no class object {5959df60-2911-11d1-b049-0020af30269a} could be created for context 0x1
err:d3d:context_choose_pixel_format Can't find a suitable iPixelFormat
wine: Unhandled page fault on write access to 0x00000004 at address 0x220076f1 (thread 0027), starting debugger...
fixme:event:wait_for_withdrawn_state window 0x20080/1200001 wait timed out
fixme:event:wait_for_withdrawn_state window 0x10096/1400002 wait timed out

Based on web searches, this doesn’t look like anything special.

I tried a 1.3 series Wine version matching one of those in the AppDB tests (1.3.28 from [url=http://wine.budgetdedicated.com/archive/binary/]an Ubuntu archive[url]) and kept getting the same crash, so at least it’s not a regression. I also tried this same HOMM3 version on a 1.5 GHz Athlon system’s Debian under Wine 1.0.1, and though that Wine will also have a crash in a matter of turns on the older Celeron, here it took a couple of entire scenarios to crash in mp3dec.asi.

Due to these results it seems for now that the relevant difference is operating frequency. Perhaps a faster CPU and memory are less likely to create the memory management circumstances triggering the crash, to the effect that the faster of my systems suffers crashes much more rarely, while the other testers on Wine 1.3 and 1.5, presumably with very modern hardware, have none at all. In conclusion: even if your system has adequate performance to run this game, that may still not be enough to have it working flawlessly. The improvement that seems to have taken place in this issue is probably not related to Wine or workarounds but rather something very incidental in system performance.

Though I’m thinking, that a Celeron shouldn’t have these issue at all, since it has only one core.

You sum up my confusion to a great extent. I’d seen the schedtool trick and ignored it as irrelevant. I tried it now with Wine 1.5.16 and sure enough the game crashes as before.

That Nvidia driver is the only one that supports my GeForce card (see e.g. here), so I can’t just try a newer version. Could an older driver do any other harm than not supporting all the OpenGL tricks the Wine DirectDraw renderer uses? In any case, Wine 1.5 and this proprietary driver give me excellent performance with HOMM3 on the Celeron with no noticeable graphical glitches, so I have no complaints about that. Nouveau doesn’t seem to have much support in Debian Squeeze and I couldn’t get it to work; I may try harder later.

I did try a newer system, the (still 32-bit) Athlon in my previous post, and got exceedingly few crashes even without any workarounds. Admittedly the X on that system uses an open-source Radeon driver, so a driver issue can perhaps not be excluded, but playing with the nv driver on the Celeron still crashes early (and is a little more sluggish). So it may be that more recent hardware helps – what with people’s AppDB reports and all – and I may get to try someone’s even newer system over christmas to see if a beefier setup really is all that’s needed. But the point was that for the time being I’m stuck with the Celeron system and wanted to see if I can do anything to make the game’s music work on that reliably. It’s starting to appear that’s not possible.

Sorry for being unclear; what I meant with the nv part was to say that it looked unlikely that my old binary Nvidia driver was at fault when the plain nv I used before showed the same crash behavior. Though I guess the deprecation thing does make nv much less reliable as a point of reference than I thought.

I was unable to get the (experimental) Nouveau driver in Debian Squeeze even to load – it failed on probing its kernel module so X couldn’t start. I haven’t yet had time to see if that’s perhaps something to do with KMS or something fixed in more up-to-date Nouveau versions.