dsoal
dsoal copied to clipboard
kcat
Build with OpenAL Soft and release Win32/64 binaries with versions
What this does:
- Address https://github.com/kcat/dsoal/issues/13#issuecomment-1086640387
- Add OpenAL Soft ~~as a submodule~~ now it gets cloned temporarily during workflow run so there's no need for a submodule anymore
- Compile DSOAL together with OpenAL Soft binaries for Windows 32 and 64 bits (Tested with RightMark 3D sound and Kodi, respectively)
- Package binaries with alsoft.ini and documentation (licenses, readmes, changelogs, etc)
- Upload master branch artifacts to GitHub actions and releases (untagged commits will be marked as pre-release so for stable releases, just add a semantic version (
x.x.x) tag). DSOAL.zip includes both Win32 and Win64 builds. - Label files using
vX.X.X(for tagged build) orYYYY-MM-DD_DSOAL_rDSOALCOMMITCOUNT@DSOALCOMMITSHORTHASH+OpenALSoft_rOPENALSOFTCOMMITCOUNT@OPENALSOFTCOMMITSHORTHASH(for untagged build) - Provide permanent and direct download locations, e.g.:
- Stable: https://github.com/ThreeDeeJay/dsoal/releases/latest https://github.com/ThreeDeeJay/dsoal/releases/latest/download/DSOAL.zip
- Development https://github.com/ThreeDeeJay/dsoal/releases/tag/latest https://github.com/ThreeDeeJay/dsoal/releases/download/latest/DSOAL.zip
- Automatically reuse
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) - Automatically add a changelog since the last branch (e.g. between stable builds)
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.
Compile DSOAL together with OpenAL Soft binaries for Windows 32 and 64 bits.
Disappointed that wasn't my wet dream, even though I guess it's the second best thing then.
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.
Meanwhile, every release note could underline this step | https://github.com/kcat/dsoal/issues/34#issuecomment-1146102230
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.
every release zip should probably include the batch file. | https://github.com/kcat/dsoal/issues/34#issuecomment-1146102230
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. Either way, I'm planning to include them in the next version of my DSOAL (and others) installer.
Not a fan of submodules, they're a maintenance headache and regularly run into issues with not updating properly.
I don't think the version.rc version should be updated like that, I think that's related to the version specified in Microsoft's DLL that some apps may depend on.
I also don't think it's yet time to jump to 1.0, since there's some issues to address with EAX.
Not a fan of submodules, they're a maintenance headache and regularly run into issues with not updating properly.
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. What maintenance issues should we be on the lookout for? I could try other methods in case they can be mitigated with extra git commands/flags.
I don't think the version.rc version should be updated like that, I think that's related to the version specified in Microsoft's DLL that some apps may depend on. I also don't think it's yet time to jump to 1.0, since there's some issues to address with EAX.
Fair enough. I'll just go ahead and revert that commit then. 👌
What maintenance issues should we be on the lookout for? I could try other methods in case they can be mitigated with extra git commands/flags.
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?)
@mirh Thanks. I think that did the trick but I'm a bit confused.
I recall the submodule not being checked out automatically by the desktop app at one point, and now they do as shown above but I'm not completely sure it's because of that flag or some other option I tried. (which I've now disabled by the way).
Like, I added the flag in a new branch, but you can see it checked out the submodule in my fork's master branch, too.
I expected the change to only apply to the new branch but perhaps it applies to the repo globally?
You guys could try cloning https://github.com/ThreeDeeJay/dsoal.git and see if you get the same behavior.
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 https://github.com/kcat/dsoal/issues/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? Because at least for the moment the first option seems preferable, given how many awful quirks come up every odd week, but at the same tame that sounds pretty bad for reproducibility.
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. as for DSOAL stable builds, perhaps they should be triggered by either stable OALS releases or at least tested milestone-ish updates.
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).
~~But you can't have both ideas implemented in .gitmodules.~~ Ok seems like actions can do more or less whatever they want, regardless. So idk really.
In fact, we should already have a release IMHO, pointing to e7a82d4fda8502eef9f8aacaa207199917d94167 (i.e. the last version before the big EAX switch). As can be seen in #53 (and plenty of other bugs I can't be bothered to search) it's a huge breaking point for every bisection.
@mirh Oh, that's right. I've encountered a handful of bugs myself after the EAX switch, tho https://github.com/kcat/openal-soft/commit/7518a8a503cbc3cc3ec30ea8872b908b044d866b fixed the last 2 I tested.
@kcat Would https://github.com/kcat/dsoal/commit/e7a82d4fda8502eef9f8aacaa207199917d94167 and https://github.com/kcat/openal-soft/commit/c1c63a27de66cd44ef756b190a73bfa8bc6dbbab be a good combination for a tentative "stable" build like, say, 0.9.1+1.22.0?
At least while I figure out the shortcomings of this PR. I've been reading some documentation and been testing a handful of improvements like automatically checkout submodules when cloning, use the last stable build of OALS for stable DSOAL, update OALS to the latest upstream commit before compiling Development build, add OALS commit hashes (Development) or tag/version (Stable), etc.
Also, would it make sense to build development binaries using the Debug build type instead of Release? If so, does it enable logging by default or something?
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? perhaps an older one, the latest or should we just wait for the next major release to consider it stable?
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. Perhaps it would be useful if it forced logging somewhere (like %APPDATA%/OpenAL/) by default to simplify bug reporting in the development build.
Not really, people can even just use the dev builds to play (indeed they are now). Aside of what I suggested in https://github.com/kcat/dsoal/issues/25, if any it would be great if there were simpler means than setting env vars to enable logging.
I see. Is there any DSOAL/ALSOFT combination that you'd consider stable/recommended for most games currently? perhaps an older one, the latest or should we just wait for the next major release to consider it stable?
There are these known problems to be solved: https://github.com/kcat/openal-soft/issues/706#issuecomment-1137846829 https://github.com/kcat/openal-soft/issues/714
and this https://github.com/kcat/dsoal/issues/39 but if I remember correctly @kcat said that in this case it took some time to implement the missing function that causes this crash
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 And I guess we could as well just link dsoal-XP as an "old odd release" to test just for peace of mind.
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.
I see. Is there any DSOAL/ALSOFT combination that you'd consider stable/recommended for most games currently?
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.
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.
1.22.1 isn't released yet, but is expected soon. The changelog shows what has been done in preparation of the release.
By the way, just noticed Debug build type doesn't seem to be used for anything in particular. Perhaps it would be useful if it forced logging somewhere (like %APPDATA%/OpenAL/) by default to simplify bug reporting in the development build.
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.
and this #39 but if I remember correctly @kcat said that in this case it took some time to implement the missing function that causes this crash
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.
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.
Pushed the update addressing some issues mentioned and builds succeeded and were released. 🎉
There's still a few things left to do though, but wanted to push this update to go with 1.22.1.
@kcat Speaking of, it seems latest openal soft commit needs a 1.22.1 tag so it reflects on the Stable builds/artifacts/releases.
I use cd openal-soft then git describe --tags to get the stable version of the OpenAL Soft submodule to label stable builds, but right now it's returning 1.22.0-79-g05f5faf2.
Then again, I know there's still no stable stable release of DSOAL, but this is just for testing purposes while we get there. 🤞
Also, I should point out that the submodule should probably be updated manually upon new OALS release with cd openal-soft then git checkout <NEW RELEASE COMMIT HASH> then push. At least unless there's a way to update to the latest tag via Github actions. 🤔
On a side note, I should also point out that currently, Development builds' releases overwrite the previous one because it re-uses the latest tag on the new commit. This allows a static direct download link that always points to the build of the latest commit via, e.g., https://github.com/ThreeDeeJay/dsoal/releases/download/latest/DSOAL.zip, but I'm not sure if it's worth using a different method so old development builds are permanently archived in Github Releases. 🤔
I just updated the GitHub actions so it doesn't require having OpenAL Soft as a submodule anymore, so instead it clones it into a subfolder during workflow run - https://github.com/ThreeDeeJay/dsoal/commit/8956eed77fd58b5a292d57fe312bb3b76f084498 Artifacts - Releases @kcat Let me know if you have any suggestions/questions 👀