Build with OpenAL Soft and release Win32/64 binaries with versions #52
Conversation
Disappointed that wasn't my wet dream, even though I guess it's the second best thing then. |
I've always wondered why DSOAL didn't just kept using OpenAL32.dll or at least soft_oal.dll like EAXEFX, and I'm not familiar with global states but I guess kcat's response explains it.
The GitHub action I used for automatic releases doesn't have a release note preset/template but I could look for another action or it could just be added manually or into Readme which I can include in the zip.
I was actually considering that. same for the other script I made for logging but I'm not sure what's @kcat's stance on including batch scripts but I could submit PRs for each. |
|
Not a fan of submodules, they're a maintenance headache and regularly run into issues with not updating properly. I don't think the I also don't think it's yet time to jump to 1.0, since there's some issues to address with EAX. |
This reverts commit 98ed525.
I see. So far, it seems to checkout the current submodule seamlessly but I'd need to wait for a commit on openal-soft to make sure it updates properly as well.
Fair enough. I'll just go ahead and revert that commit then. 👌 |
They don't automatically checkout with the repo, they don't automatically update when updating the repo, bisecting or switching between commits or branches that use different versions need extra steps to keep consistent, and the commands to use can get confusing, which when done wrong, can make it look like everything's fine and correct when it's not. As an optional thing that only GitHub Actions need to worry about for the binary packages, it may not be a big deal, but having it there for users to see and think they need when building themselves could cause unnecessary problems. |
|
I don't think users that want to build the thing themselves are so clueless to mix up buttons. Anyway, putting aside git hooks, I believe you can specify some option in the .gitmodules file? (fetchRecurseSubmodules maybe?) |
|
That said, I'm willing to look into the other issues, but I also don't wanna impose a burden on the devs/users with further complications of submodules. So if this isn't the appropriate solution to #13, I don't mind just building the binaries on my fork and figure out how to make it fetch upstream automatically or something 🤔 |
|
If you are confused, maybe it's something with the nuance between fetch, pull, checkout and update (I mean, that's the case for me at least) But if any, the actually big conundrum for subdmodules seem: regardless of what we can do with git, should we always point to the HEAD of openal-soft, or just to some fixed commit that we bump every time as we deem fit? |
yeah, I'd suggest a bit of both. I think DSOAL development builds should just use a recent/latest OpenAL Soft at the time (but we should probably also include the OALS commit hash to help with reproducibility) to keep up with debugging and hotfixes like this. |
|
I guess it makes sense for actions to point to the tip, and the release section to just have "hand-picked" versions (whenever circumstances will be rosy enough to have an official release).
|
|
@mirh Oh, that's right. I've encountered a handful of bugs myself after the EAX switch, tho kcat/openal-soft@7518a8a fixed the last 2 I tested. @kcat Would e7a82d4 and kcat/openal-soft@c1c63a2 be a good combination for a tentative "stable" build like, say, 0.9.1+1.22.0? Also, would it make sense to build development binaries using the Debug build type instead of Release? |
|
I wouldn't consider those two particularly stable. While the switch to the EAX API has caused some issues, there were issues with using the EFX API that got fixed or improved. And OpenAL Soft 1.22.0 has a known issue with air absorption being way too strong. |
|
I see. Is there any DSOAL/ALSOFT combination that you'd consider stable/recommended for most games currently? EDIT: apparently there's OpenAL Soft v1.22.1 according to the changelog, but there are no tags or releases anywhere. I take it that should be the actual latest stable OALS build. By the way, just noticed Debug build type doesn't seem to be used for anything in particular. |
|
Not really, people can even just use the dev builds to play (indeed they are now). |
There are these known problems to be solved: and this After that, DSOAL/OpenAL Soft should be good enough. I'm not playing EAX games right now but if I notice any other issues I will report them 👌 |
|
#39 isn't a regression So, premised that perfectionism is the same thing that had pcsx2 took 3-4 years between official stable versions (somehow letting "best" to ruin "better"), and that the EAX switch isn't as big of a change as I thought (indeed #53 seems to be caused for other reasons) maybe we should just wait for a fix of the other two problems and the next official openal-soft release. |
Not really, if there was one I thought was stable enough for a release, there would've been a release (or at least an indication of stability). My recommendation is to try the latest version and report bugs so I can try to fix them. If there's an issue with a particular game you want to play, and an earlier version doesn't have the issue, use that earlier version until it can be fixed, but that'll depend on the game/issue, I can't give a general recommendation.
1.22.1 isn't released yet, but is expected soon. The changelog shows what has been done in preparation of the release.
Logging on Windows is something I've never got a grasp on. Simply dumping a random file to a place on disk without the user expecting it doesn't seem like a good idea.
That it will take some time. Or I may not be able to implement it at all. DSound's native effect API is quite different from EAX and EFX, and it was never widely used, so it will take some time to understand how it's supposed to work and try to emulate it alongside EAX. I'm honestly not too worried about that specific issue, though. As I said, DSound's effect API wasn't widely used, and that particular case has a workaround of turning off the radio EQ option. There may also be a way of working around it without implementing it by handling effect errors properly, if there's some incorrect behavior there. But that's something to worry about after the EAX issues are fixed. |
Absolutely, the other two problems are more serious, fortunately this is easily avoidable. |
- Appends tag/version/git describe of both DSOAL and OpenAL Soft to Stable builds, and commit hashes to Development builds. - Update OpenAL Soft submodule to the latest commit for Development builds, and set to 1.22.1 for Stable builds. - Include Documentation (licenses, readmes, changelog, etc) - Set Debug build type for Development builds - Removed "-latest" from 32+64-bit bundle artifact which became misleading on new builds - General cleanup
|
Pushed the update addressing some issues mentioned and builds succeeded and were released. 🎉 On a side note, I should also point out that currently, Development builds' releases overwrite the previous one because it re-uses the |
You don't have to mess with anything.. just drop soft_oal.dll in place.
I don't think it's even possible without going through the painstaking process of stealing TrustedInstaller's ownership
This is how openal was ever supposed to be used tbh..
At the moment this still isn't the case anyway
Dsoal uses (even though I don't think they are actually too much of a hard requirement?) oal-soft specific extensions.
IF my theory is right, the theory that I spent weeks banging my head against, the theory that somehow got everybody else to stop to care once I detailed it, yes they do require the registry patch too.
I mean.. simplicity and letting you switch even between different A3D wrappers and the godawful 3dsoundback, don't seem exactly to go hand-in-hand. |
I know about this what directsound wrapper doesnt need for openal games like UT2004. But you dont know how to replaced Openal in Minecraft 1.16.5? I know what in this game doesnt have good sound like unreal, dungeoon siege 1, warcraft 3 or another but i trying increase sound quality in this game and maybe add some spatial. In new versions (if im right correct) like 1.20 or 1.19 game officially using openal soft, but in old not. Only one way i can find its replace two dlls (who would have thought)) in folder C:\Users\Myname\AppData\Roaming\com.modrinth.theseus\meta\natives\1.16.5-1.16.5-36.2.39 if using Modrinth launcher if curseforge i afraid its very hard because curselauncher launch the game through official launcher that replacing your dlls before launching. |
It's necessary for apps that use both OpenAL and DirectSound (even if indirectly; e.g. a game that uses DirectShow for music playback, which can use DSound, while game audio uses OpenAL). An issue like this popped up in the game Legendary, which used Unreal Engine 3. The menus and/or videos would use DSound, while the game audio used OpenAL; this caused problems as the DSound calls were changing the OpenAL context that the engine was using (or maybe it was the engine changing the context that DSOAL was using, I forget exactly), resulting in calls being made on the wrong OpenAL context. The original attempted fix was to constantly set and reset the context in DSound calls, but aside from increased overhead, this could still fail if it was being done multi-threaded; DSound can't prevent the engine from making its own OpenAL calls on other threads. A better fix was to utilize the Having DSOAL use a differently-named DLL was the only guaranteed solution that could avoid most of the overhead from constantly resetting contexts on every DSound call and ensure the app is safe with any OpenAL calls it makes. FWIW, the in-progress
I don't think current master has any hard requirements, but you'll certainly be open to issues if certain extensions aren't available. Without The Most importantly in either case, the implementation has to be able to accept stringified GUIDs for device names, which is completely non-standard and has no extension to specify the capability. It also can't work through the router since none of the drivers enumerate them (the router has no idea which driver to pass the call on to). |
@mirh But how would we make sure it actually uses soft_oal.dll instead of a different library?
@mirh Oh that's right. I used a reg key that adds Take Ownership to the right-click menu so it's easy but yeah, otherwise I doubt a new user would figure out the manual method on their own lol
@mirh Yeah I know, but if we're installing OpenAL Soft, chances are we want to use OpenAL Soft, not have it be overridden by a different library. but then again, I'm not really up to speed on how much priority it has over other libraries or how to give it more if needed.
@mirh How so? If I wanted to test the latest (or multiple) OpenAL Soft DLL in several apps without having to install it locally for each .exe, I'd just replace OpenAL32.dll in the system folder (and delete the local DLL, if it exists) but as a general rule I prefer to install DLLs locally so that updating a system/global one wouldn't break apps in case of a regression. Plus, I think replacing the generic/router DLL can make startup faster, which I remember happening in EFXShow
@mirh Interesting. makes sense 👌
You're completely right. Here's a recording on Windows 7 showing the registry patch being required like the one I made for Windows 11 that I posted here a while ago.
@mirh To be fair, other wrappers/renderers are there for people wanting to use/test them.
@iAskel I don't have the game so I can't test myself, but that game's been discussed a couple times in our server. I recall it loading OpenAL in a strange way, like the dll being extracted into a folder before the game starts, which makes it difficult to replace. But I was told that if you use the Prism Launcher you can make it use the system's OpenAL instead, like this.
@iAskel Apparently Minecraft comes with OpenAL Soft, but it might be an older version and the sound quality issues might be caused by poor sound code. |
Tbh I'm surprised this doesn't/didn't happen more often then? Bink videos using directsound and the 3D scene using openal isn't exactly a rarity (even though conversely, it wouldn't really make sense to use dsoal)
Meaning.. you don't need to place two dlls every time?
Why so?
If you know how openal works, and you read and understood kcat/openal-soft#757 it should be clear..
I guess (I could only see this not working if the game did integrity checks on its libs?), but that's an extra step.. like on every game.
A perverse mind could argue that in turn that would make way easier to spot said hypothetical regression. |
The issue was fixed well enough when I first noticed it, so it's probably not apparent how often it happens. I also doubt many people would bother using DSOAL for games that use OpenAL natively.
Well, you'd still need OpenAL Soft, which most systems won't have installed system-wide, so you'll still need to provide an OpenAL Soft DLL with dsound.dll. And newer versions of DSOAL may want newer versions of OpenAL Soft that the user may not have. But if you already have a sufficiently recent OpenAL Soft DLL, then no, you wouldn't need to update both DLLs.
Because OpenAL offers no way to identify its enumerated devices by GUID, and Windows uses the same GUID consistently for the same device across APIs. OpenAL can also dress its device names differently than the rest of the system (e.g. prepend This is something else I've wanted to fix. I really don't like how standard enumeration works with OpenAL, how you only get a null-separated list of user-readable device names. Aside from a null-separated string being wonky to deal with, there's no concession for if two devices have the same display name, and there's no way to match them to system devices. I'd instead prefer an API where you first query the number of playback or capture devices (which does the actual system probing), then use an |
In your manual said: Extract and rename soft_oal.dll to OpenAL32.dll (or a variant if the game uses it) and copy it to the "prismlauncher-windows-msvc-portable-6.0" folder Prisma launcher doesn't have this folder, and why are you testing it on the portable version? It feels like you are using linux. Maybe you can just install the game and prisma launcher and just test it? Otherwise how do you know if a particular game is working correctly, is it by guessing? In other words, only in theory, without testing anything. If im right... I'm afraid the table you are referring above to won't help nobody. |
Basically ported PR kcat#52 into the rewrite branch
Basically ported PR kcat#52 into the rewrite branch
|
Is it possible to use Creative's OpenAL library to bring back hardware accelerated DirectSound for newer Windows versions? |
ALchemy, which requires and comes with either a Creative sound card, or one of their paid software "sound card" solutions. I'm not aware of anything that works with the free Generic Software driver, though. |
Alchemy only has 32-bit binaries. I want to offload my CPU in Counter-Strike 2 which can use DirectSound using -directsound launch parameter. I tried renaming OpenAL32.dll to dsoal-aldrv.dll and got no sound with DSOAL's dsound.dll also tried renaming wrap_oal.dll to dsoal-aldrv.dll and got glitchy sound. Maybe someone could bugfix this? I have Creative X-Fi Titanium 64MB X-RAM |
@iAskel Sorry I missed this message, and I can't test myself but I was told the latest version does use OpenAL Soft 1.23.0 (and even has an HRTF toggle in-game) which is relatively recent but remind me, but I still don't know how to force replace the OpenAL library in older Minecraft versions. If you ever figure it out, let me know.
@Svyatpro AFAIK Source games (old CSGO, HL2, etc.) use Miles Sound System for mixing(?) and DirectSound (or DirectSound3D with IIRC for hardware acceleration with an X-Fi on modern Windows, the game needs to use DirectSound3D (mostly mid-late 2000's and older) wrapped by Creative ALchemy using ct_oal.dll (Native OpenAL driver) or interfacing directly with OpenAL hardware like Battlefield 2. On a side note, I'd be extremely careful with loading third-party DLLs in CS2. I think even CSGO required parameters like |
I found a vulnerability how to make it work without "-allow_third_party_software" parameter. Actually Alchemy was able to offload CPU and noticibly reduce the latency on Source and GldSrc engines. Source 2 is now using 64-bit architecture and Alchemy cannot be used. I also tried cl_oal.dll but nothing works. It seems new DSOAL uses EAXGet and EAXSet functions that are not present in OpeanAL32.dll and ct_oal.dll. Maybe it is possible to make altrenative OpenAL driver loading method? For example delay-load openal32.dll or dsoal-aldrv.dll and check the device features and presence? |
Interesting, how did you manage to do it? copying dsound.dll into the system32 folder? 🤔
Apparently GoldSrc had proper DirectSound3D support with EAX so it could probably use hardware acceleration, though it was removed in games like Half-Life. |
Yes, I'm pretty sure the sound in CS GO with Alchemy was serveral tens of milliseconds faster but the performance difference I did not measure. BTW DSOAL with SoftOpenAL has a huge sound delay in CS2 and 1.6. I will open feature request though. Thanks! |
- Separate release build (DSOAL+HRTF.zip) with a alsoft.ini that has the minimal configuration for HRTF, and the template moved to the Documentation folder (DSOAL.zip will still include the template next to the DLL files) - Included Version.txt files including repo, branch, version, commit short hash, count and push time - Versioned files now only found in the workflow artifacts for a cleaner release and to prevent confusion - Untagged release now includes branch (e.g. latest-master) so that the rewrite branch can get its own releases (didn't use just the branch name in the tag because that makes the GitHub client confuse it with the actual branch when trying to push) - Updated actions to fix workflow warnings - General cleanup
|
As promised, here's the update to be consistent with kcat/openal-soft#1008, as well as other improvements and fixes: @kcat Any thoughts? |
What this does:
as a submodulenow it gets cloned temporarily during workflow run so there's no need for a submodule anymorex.x.x) tag). DSOAL.zip includes both Win32 and Win64 builds.vX.X.X(for tagged build) orYYYY-MM-DD_DSOAL_rDSOALCOMMITCOUNT@DSOALCOMMITSHORTHASH+OpenALSoft_rOPENALSOFTCOMMITCOUNT@OPENALSOFTCOMMITSHORTHASH(for untagged build)https://github.com/ThreeDeeJay/dsoal/releases/latest
https://github.com/ThreeDeeJay/dsoal/releases/latest/download/DSOAL.zip
https://github.com/ThreeDeeJay/dsoal/releases/tag/latest
https://github.com/ThreeDeeJay/dsoal/releases/download/latest/DSOAL.zip
latesttag for development builds so only the last one is shown on the GitHub Release page (that way stable releases/milestones are easier to scroll through)This should hopefully make things easier for everyone and I know there's still lots of room for improvement so I'm open to suggestions.