search

kcat / openal-soft

OpenAL Soft is a software implementation of the OpenAL 3D audio API.
Other
2.22k stars 536 forks source link

DEF-to-MHR issues #1027

Closed Kekkin closed 3 months ago

Kekkin commented 3 months ago

Was trying the latest github actions build (at that time it was from Aug 1.) to create a HRTF profile (particularly, IRC_1037). While the makemhr tool parsed the .def file successfully and created the profile from the .wav set, checking openal-info led me to this error:

[ALSOFT] (EE) Failed to load IRC_1037

Using latest OpenAL Soft release (1.23.1). The bundled makemhr parsed the file fine and there were no problems loading it according to openal-info. I have been bisecting commits to see which commit was problematic, and from what I deduced it's because of commit 47c1158 (Builds of makemhr from commits before that one don't exhibit this problem, at least for this particular HRTF profile).

IRC_1037.gz

kcat commented 3 months ago

Should hopefully be fixed with commit 2d6520928c0b8247959fb0307fcad698a688e40f, presuming the issue was text mode conversions when writing files.

Kekkin commented 3 months ago

While it did solve the Invalid delays issue, I've noticed that the IRC_1027 MHR profile built with the commit 2d65209 artifact build of makemhr sounds awfully off, compared to the MHR profile compiled via 0.23.1's MakeMHR, the pre-built MHR from the HRTF Database, and the MHR profile which was built from the 379d9cfb build of this tool (last commit before the one that caused the initial "Invalid delays" problem).

I've tested these profiles with Mirror's Edge.

The samplerate-agnostic MHR profile didn't even load at all, even though the game is properly configured to use OpenAL-Soft libraries. The 48kHZ one sounds awful, compared to the known-properly-working profiles I had tested. (note Faith's grunts, footsteps and breathing being strangely muffled/canned-sounding compared to the rest of the soundstage). https://files.catbox.moe/4xoso5.webm - bad sounding profile https://files.catbox.moe/pm7uav.webm - good sounding profile

I've attached archives containing working (379d9cfb), and not working (made of the latest MakeMHR artifact) profiles. You might want to notice the scale of compression in both of these archives. (the compressions settings were exactly same for both). HRTF_bad.tar.gz HRTF_good.tar.gz

kcat commented 3 months ago

It's seeming like there's something wrong with istream/ostreams on Windows, given the reported problem in PR #1026 too. Even with the binary flag set, it's apparently not reading/writing certain bytes properly. Though in this case, it's writing and not reporting an error, so maybe not. But that seems to be the only relevant change to makemhr since the working commit.

It's odd that it doesn't seem to be a problem for loading mhr files. I haven't seen or heard of any problem with them loading, despite the same functions being used to read. I might need to switch back to the C-based FILE* methods, at least temporarily to see if that fixes it.

kcat commented 3 months ago

Actually I'm noticing the same problem here on Linux too, the samples end up in repeating patterns that's obviously incorrect. It doesn't happen with the MIT KEMAR SOFA files, leading me to believe something may have broken with the .def source loader (something I'm not too fond of keeping given SOFA support, but it should be kept working as long as it's there).

kcat commented 3 months ago

Should be fixed now with commit a3eb86307ceb7c5f26b583c40e119913af73e12a. span::subspan() vs span::first() strikes again.

Kekkin commented 3 months ago

Should be fixed now with commit a3eb863. span::subspan() vs span::first() strikes again.

Had a test run with it, and I'm convinced it sounds as it should now. Both on sample-rate-agnostic & 48kHz profile. Gotta have to check the SOFA format, though. Most of the HRTF profile generating guides for OASoft were talking about the old-school .def way, so I've gone into that. Like I said, it works as it should. Thank you!