Support for Windows XP/98

[t9999clint]

It was mentioned in kcat/openal-soft#506 that DSOAL depends on MMDevAPI/WASAPI in order to output sound.
Would it be possible to allow a waveout option or something simular to allow for older windows versions to use DSOAL?

Windows 10 is becoming less and less usable for older games and so I've switched to a number of Windows VMs that I use to play older games (Windows 3.1, 98, XP, etc..).
I have found solutions for Video acceleration for these VMs but audio still doesn't sound right. I've tried pci passthrough on old soundblaster cards, but these old cards don't work well with IOMMU.
While using Windows 10 I've noticed that your DSOAL gives the best software solution for DirectSound support, but sadly it only works with Vista and later. If you would add a legacy option/build for Windows XP (and maybe even 98), than it would allow for easy full emulation of Windows 98/XP era games. I know a bunch of people on the Vogons forums that are also looking for a XP/98 compatible solution for this.

[bjb43]

I, too, would be very happy about WinXP support. May I ask: Which is the last version of openal-soft, that still works under WinXP? Thanks a lot for your work!

[mirh]

I have yet to see a game that couldn't be made to work eventually (even though, I'll grant windows 10 has nothing stable, and it's always a lottery compared to W7) And save for whenever AMD has zero testing on their motherboards, the only thing to remember for passthrough should be to reserve the sound card device id.

Anyway, there is an XP fork in the works but I'm not really sure about performance. MME should have terrible latency. @pachuco The only other standard audio API older windows gave you is WDM/KS.

[t9999clint]

Glad to know there's a XP branch already available. I'll give it a shot, hopefully it'll be good enough for now.

Regarding PCI passthrough of Soundblaster cards, I've had to avoid AMD boards for this because of poor/missing support. I'm using a X99 mobo. GPU and USB PCI-E passthrough is working fine, but something about the soundcard drivers hate being in a VM. WaveOut works fine, but nothing else does. My guess is that it's some kind of PCIe timing issue. Regardless that's irrelevant for this feature request.

Would WDM/KS be too difficult to implement to be worth it for this project, or is there some other thing preventing XP support from being added? Win 98 support would be even better for me IMHO, but I'm not expecting anyone to go through the hardwork required for that.

[mirh]

The base openal router should already support W98.. so, I guess that's already a first step at least?

Though I just discovered WDM-KS opens the audio device exclusively, so I'm not sure that's really the win-win I was imaging. Perhaps there's some way to use "directsound hardware" (i.e. meaning that you aren't just forced to stereo and zero effects), without actually data having to be processed by the sound card driver that we can't control? But I somewhat feel like that's outside the scope of openal.

[kcat]

The main issue with supporting XP and earlier is using an audio output API. Given that DSOAL implements DirectSound, having OpenAL use DirectSound for output would cause a dependency loop. WinMM can also use DirectSound under the hood. OpenAL Soft would need to force the use of the system dsound.dll, or DSOAL would have to piggyback on the system dsound while using a loopback device for rendering. WDM/KS is outside my area of knowledge.

As for the latest version of OpenAL Soft that supports XP, that was never explicitly broken, but given that there are so few users, I have no idea what the last version is that works (if the current version doesn't).

[bjb43]

Thanks for the info regarding openalsoft on XP. I'll try different versions then :)

The dsoal winxp fork does not seem to work for me so far, if anyone was successful, please let me know.

[pachuco]

@bjb43 oh derp, forgot to enable issues. You can report troubles with the XP fork on its respective page.

[bjb43]

@pachuco Thanks a lot! I opened an issue there. Anyways: Thanks @ all for your great work!

[mirh]

I could swear I had already seen another discussion on this, but remind me again how dsoal (and thus openal-soft) can fallback to directsound without actually being constrained by the same limitations that had you wishing to replace directsound to begin with?

[t9999clint]

bjb43, most games don't seem to work but a bunch still do.
Windows XP support is somewhat working with Pachuco's fork, so It's a good start at least.
There's a good 200ms delay that I've been able to notice in the audio that's rendered this way, which is a lot but it's still useable.
It'd be nice to see this integrated with the mainline DSOAL. Of course only if it doesn't break anything for modern versions of windows.
I'm not much of a coder but I'll be happy to help out in testing games for you if you'd like.

[pachuco]

Out of sheer curiosity, I had a go with dependency walker on my dsoal fork and softoal, for missing functions in Windows 98 VM:

dsoal

• kernel32.CreateTimerQueueTimer
• kernel32.DeleteTimerQueueTimer
• kernel32.GetModuleHandleExW

soft openal:

• kernel32.AddVectoredExceptionHandler
• kernel32.GetModuleHandleExW
• kernel32.RemoveVectoredExceptionHandler
• kernel32.SetFilePointerEx
• msvcrt.___mb_cur_max_func
• msvcrt._aligned_free
• msvcrt._aligned_malloc

And *W functions need unicows and similar.

So, this would probably mean downgrading some code, separate softoal fork. Secondly, what are softoal cpu and memory requirements and is running softoal on win98 hardware even feasible?

[kcat]

OpenAL Soft's CPU and memory requirements are pretty low, for modern standards. I didn't have any real problem with it when I was using a 10+ year old system, though some features may be heavier than others (like bsinc resampling or HRTF). I don't know how it would fare on Win98-era hardware, but it might be okay if you don't do anything too CPU heavy like that. The bigger issue may be that I don't think Win98 supports SSE, so the lack of SSE2 would be holding it back.

Beyond that, you'd need a C++14 compiler that can target Win98, and not generate calls to functions it doesn't have. The kernel32.GetModuleHandleExW call would be easy to remove on special builds, kernel32.SetFilePointerEx might be replaceable with SetFilePointer, and msvcrt._aligned_* are only used when detected at cmake time. The other function calls are the result of the compiler.

For DSOAL, the TimerQueue functions would be more of an issue. They're needed for triggering notifications and possibly keeping streams fed. There might be a way around it, but it would be more costly on the CPU.

[pachuco]

Windows 98SE supported SSE1, so maybeprobablyperhaps newer variants are automatically supported due to having same registers.

[mirh]

You could probably even get SSE to work in 95 with some luck http://www.vcfed.org/forum/showthread.php?63258-Does-Windows-95-really-have-an-SSE-bug-(Pentium-III) And there's also KernelEx for certain normal OS functions.

[pachuco]

That luck being "only one application executing SSE at a time" :p

[kcat]

I guess technically it would be "only one thread". A single app using multiple threads with SSE would see similar corruption from each thread manipulating the registers as they get scheduled in and out. Multi-core CPUs would be a fun one to see, though I wouldn't be surprised if Win9x (or even early NT) didn't support them.

Though if Win98SE supports SSE, that should be good enough for OpenAL Soft to not have problems using SSE itself. SSE2 preferably, as that fully supercedes the x87 for most applications (unless you really need those 80 bits instead of 64), and the x87 is pretty terrible when it comes to performance of denormal values, which are easy to hit with decaying feedback loops that various DSP algorithms use. SSE can disable denormals and treat them as 0 since they're so small anyway, but I don't think that affects x87 processing. The main thing then will be finding a compiler that can target Win98, or find some other way to deal with the missing functions.

[t9999clint]

NT4.0 I think was the first version of Windows that supported multiple cores. None of the Win9X operating systems supported more than one core. There are hacky workarounds, but it's not really worth using. I'm gonna have to give it try with KernelEX and see how that works.

In terms of Win9x/ME compatible hardware being too slow, on some systems yes, but there's a very wide range of systems that supported Windows 9x/ME. Basically 66mhz 486DX2 all the way up to 1.8ghz Pentium 4 This is a complete guess but, on anything lower than a 400mhz cpu, I wouldn't expect this to work well at all, but on something closer to 1ghz it shouldn't be a noticeable performance impact.

[mirh]

https://stackoverflow.com/questions/25596221/g-programs-for-windows-98#comment115771308_50849554 Even rust should be doable!

[Allanon41]

Win98SE does support MMX and can be modded to work with SSE and on up to AVX.