search

kcat / dsoal

A DirectSound DLL replacer that enables surround sound, HRTF, and EAX support via OpenAL Soft
GNU Lesser General Public License v2.1
388 stars 50 forks source link

Support for Windows XP/98 #22

Open t9999clint opened 3 years ago

t9999clint commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

bjb43 commented 3 years ago

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

mirh commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

soft openal:

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 commented 3 years ago

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 commented 3 years ago

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

mirh commented 3 years ago

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 commented 3 years ago

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

kcat commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

Allanon41 commented 4 months ago

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

Torinde commented 2 months ago

Win98 supports SSEx (incl. SSE2) natively. SIMD95 enables hacky support for SSE in Win95 and for AVX/2 in Win95 and 98.

Performance-wise - as mentioned above Win9x/XP run on a variety of hardware, including fast machines above 1GHz. There are also hypervisors and emulators.

So, it's definitely worth to investigate that.

mirh commented 2 months ago

@dechamps hoping all this masterminding isn't an annoyance.. For all the relative praise WaveRT gets, once that isn't available how good are WaveCyclic or WavePci? Is each of them their own separate thing, or could much of the code be recycled?

I'll grant I'm surprised the directsound wrapped in directsound idea worked as good as it did, but it would be marvellous if somehow trying to lower the latency in W10 automatically gained you support for W98 too.

dechamps commented 2 months ago

For all the relative praise WaveRT gets, once that isn't available how good are WaveCyclic or WavePci?

WaveCyclic and WavePci are not as good as WaveRT, but they're still perfectly fine for most use cases AFAIK. I'm not sure why you're asking that question though, given you don't really have a choice in the matter - on pre-Vista, it's either WaveCyclic, WavePci, or no sound at all. (Aside from ASIO, that is.)

Is each of them their own separate thing, or could much of the code be recycled?

I'm not intimately familiar with WDM/KS audio client code as I like to keep my sanity. My (limited) understanding is a lot of the complexity has to do with device enumeration, which AFAIK should look the same regardless of which "mode" the driver supports. I would suggest you look at the PortAudio WDM/KS client for sample code.

I would expect that most of the challenges with implementing a WDM/KS client have to do with testing with a variety of hardware to uncover and work around various driver quirks. With WDM/KS you are dealing directly with the Windows audio driver for the particular device - there is no intermediate layer to try to hide driver bugs/oddities for you.

pachuco commented 2 months ago

WaveCyclic was easy to program to progam for, but inneficient, hard to get latencies below 20ms. A buffer is written to and then the driver copies it over.

WavePci solved the latency issue, but was hell to program for, because special synchronization was needed. This model was avoided most of the time by driver manufacturers.

Then came win vista and later and the WaveRt model. It had the simplicity of WaveCyclic model, but the efficiency of WavePci. It did away with the memcpy of buffer. Instead, a piece of memory was shared between user and driver.

mirh commented 2 months ago

given you don't really have a choice in the matter - on pre-Vista, it's either WaveCyclic, WavePci, or no sound at all.

I mean, as I was saying.. Dsoal-XP currently wraps dsoal inside of directsound itself. That works (since if XP's dsound.dll was always the golden standard to replicate, if you are natively using the OS a light shim approach is also possible) but it's not like something that could ever be merged and developed upstream.

I would suggest you look at the PortAudio WDM/KS client for sample code.

Sure. Like, by now I don't even think it's really much sensible to develop for WDMKS without just relying on that driver with 25 years of experience behind.

WaveCyclic was easy to program to progam for, but inneficient, hard to get latencies below 20ms.

Tbh 20ms actually still sounds like blazing fast compared to the normal latency of kmixer, isn't it?

Btw are you planning any other work on dsoal-xp?

dechamps commented 2 months ago

I mean, as I was saying.. Dsoal-XP currently wraps dsoal inside of directsound itself.

To be honest I have no idea what this "dsoal" thing is about - I was summoned here by a drive-by comment and feel like I'm missing some background. My point is, whatever this thing is, eventually it has to bottom out to WaveCyclic or WavePci somehow, unless you are referring to a completely separate pipeline that somehow bypasses the entire WDM audio driver model and does its own thing on the side (like some ASIO drivers might). DirectSound itself will always bottom out to WDM/KS (via WASAPI on Vista+).