Running SDL ports on multicore processors

[Quasar]

If you have a multicore processor, the Windows versions of SDL-based DOOM ports may suffer random sound-related crashes.

To fix this, you need to check out the instructions on this page:

http://articles.techrepublic.com.com/5100-10878_11-6168870.html

This will enable you to set the processor affinity for the port in question, allowing it to behave like it is executing on a single-core processor. This appears to eliminate SDL_mixer's unexplained problems with running on a separate core.

Addendum:

For port authors, it may be prudent to look up information on the SetProcessAffinityMask Windows API function:
http://msdn2.microsoft.com/en-us/library/ms686223(VS.85).aspx

[fraggle]

PrBoom-plus and Chocolate Doom already have a fix for this that entryway developed :-)

[Quasar]

fraggle said:

PrBoom-plus and Chocolate Doom already have a fix for this that entryway developed :-)

Care to share the details? ;)

[fraggle]

Quasar said:

Care to share the details? ;)

This is the commit to the Chocolate Doom svn.

[entryway]

http://www.doomworld.com/vb/showthread.php?s=&postid=692425#post692425

http://pastebin.com/m69510e52

[Quasar]

Thanks guys ;)

[Csonicgo]

Has this been added to EE yet?

[Quasar]

Not yet, it'll be in the next official release though.

[entryway]

Quasar said:

Not yet, it'll be in the next official release though.

You should fix such things more quickly IMHO (immediately?), because it is impossible to use your port on all up to date (most?) systems. 3.33.33.1 would be cool in the same day you got to know it.

Look at this and replace "prboom" with "Eternity"
http://www.doomworld.com/vb/showthread.php?s=&postid=699166#post699166

[Quasar]

I should ;)

One question I have is still outstanding, however. It is possible for Windows machines to have access denied to particular users to run processes on a given CPU. If this is the case, then the system processor affinity mask may not be "1" or "2" or any other particular value. While it is unlikely that this would affect the vast majority of DOOM source port users, I'd like to know why the approach of just using "1" as the process's affinity mask is valid when MSDN docs demand that you make certain the mask you set is a subset of the system mask. :)

I can imagine that the consequences of setting the affinity mask to an invalid value would be an application stall or crash, or at the least, failure to actually do anything at all.

[entryway]

I do not use 1 as constant, I use process_affinity_mask variable from cfg and you can set it to any value. 1 is by default and it means the first processor. Is it possible when the first processor is not allowed, but some other is allowed? I assumed there is no such possibility. In any case if SetProcessAffinityMask failed you can see it in stdout.txt:

M_LoadDefaults: Load system defaults.
 default file: D:\games\Doom2/glboom-plus.cfg
 found D:\games\Doom2/prboom-plus.wad
I_SetAffinityMask: failed to set process affinity mask (errorcode: 87)

With wrong process_affinity_mask GetLastError() will return 87 - "The parameter is incorrect"

[Quasar]

Ahh, ok. Thanks.

[fraggle]

I'm bumping an old thread here, but hopefully with good reason. There seems to have been a lot of development activity on SDL_mixer in recent months - Mac OS X native MIDI playback has now been fixed, for example. Looking through the logs, I stumbled across this. Is this possibly related to the SDL multicore lockups? Perhaps someone with a multicore system could try disabling the affinity workaround and running the game with a recent version of SDL_mixer to see if it makes any difference? (I ask because I don't currently have access to a multicore system)

[entryway]

fraggle said:

Perhaps someone with a multicore system could try disabling the affinity workaround and running the game with a recent version of SDL_mixer

I tried it 2 months ago (with a few timedemos of cybersky max run) and did not get that crash, but I know it is not easy to get it intentionally

[fraggle]

I think my testing process was something like: start a level, set IDDQD, get some monsters to start attacking me (so that sounds are constantly generated; the more monsters the better) and leave the game running for several hours.

[entryway]

SDL_mixer related crash did not occur with -nomusic. At least with prboom-plus.

[Quasar]

Eternity doesn't use any of the functions mentioned in that bug tracker and yet is still subject to the multicore crash bugs. The only parts of SDL_mixer that EE uses are the postmix callback and the music playing.

[Quasar]

http://bugzilla.libsdl.org/show_bug.cgi?id=629

Recently updated after I caught the crash on my Windows 7 quad core box. Yes, it's still there. Yes, it's still random. Yes, it's definitely to do with MIDI.

However what is not explained is how this could possibly affect Linux, because the crash occurred in the winmm subsystem, which makes me look in the general direction of SDL_mixer's MCI callback in the win32 native midi module.

[DaniJ]

Apologies for the necro bump but I'd like an update from the other port authors as to how they're getting on with this problem.

I'm currently looking at doing something about this in Doomsday but I'd really prefer not to limit everything to a single core.

[Quasar]

DaniJ said:

Apologies for the necro bump but I'd like an update from the other port authors as to how they're getting on with this problem.

I'm currently looking at doing something about this in Doomsday but I'd really prefer not to limit everything to a single core.

No change in the situation as far as I know. It's as crappy as it ever was.

[DaniJ]

Bummer. Ok, I'll need to do some reorganising of our plugin loading in that case as we shouldn't restrict if the user is using say DirectSound.

[RestlessRodent]

I just dumped SDL_Mixer completely and implemented Win32 MIDI and Linux OSS MIDI Support, it's limited but it saves time from fixing something you might not have control over.

[Graf Zahl]

GhostlyDeath said:

Win32 MIDI

This doesn't work well on most modern systems. If you want to remove something that's broken do not replace it with something else that's also broken.

[RestlessRodent]

Graf Zahl said:

This doesn't work well on most modern systems. If you want to remove something that's broken do not replace it with something else that's also broken.

The midiOut* functions worked perfectly fine for me, at least on Vista.

[Graf Zahl]

What sound card do you have? On my onboard chip the volume is so low that it's totally unusable and Microsoft in their infinite wisdom have removed the volume control so there's nothing I can do. Any program that uses system MIDI for music is worthless for me.

[RestlessRodent]

Graf Zahl said:

What sound card do you have? On my onboard chip the volume is so low that it's totally unusable and Microsoft in their infinite wisdom have removed the volume control so there's nothing I can do. Any program that uses system MIDI for music is worthless for me.

Was some onboard AC97 Nvidia. afaik.