Claw: Missing SFX and lower volume

[RavenMacDaddy]

Homepage (unofficial): https://captainclaw.net/en/

Monolith no longer sells it, not even through something like GOG, and has no dedicated page for the game.

Instead a version with fixes for modern releases of Windows can be downloaded on the link above.

---

Playing with the latest release which is based on OpenAL Soft 1.22 (unknown if this was an issue with previous versions of DSOAL), there are missing SFX, like the trumpet when starting levels, or when picking up treasure.

The volume is also significantly lower compared to not using the wrapper.

---

Changed settings from defaults:

• Resampler quality: Cubic

---

OS: Windows 11 - 22H2 - 22621.1

[mirh]

Lower volume might actually be proper behaviour. Assuming the game was previously stuck to just using stereo, it may be that now a lot of the soundscape is getting spread to other channels.
.. or it may be a bug idk (perhaps a variation of #51).

Playing with the latest release which is based on OpenAL Soft 1.22

Not true. Dsoal is not "based" on any specific openal-soft version. It uses whatever it finds.
(even though since fe2978f you could say it's "more based" on openal-soft)

unknown if this was an issue with previous versions of DSOAL

Test it!
You can try older versions/mixes of both things if you have time to spare.
http://vaporeon.io/hosted/dsoal-builds/
https://openal-soft.org/openal-binaries/

[RavenMacDaddy]

Interesting...it does work with r422, the previous release.

Using the dsound.dll from that version with the dsoal-aldrv.dll (OpenAL Soft v1.22) from r430 works, so that means it's the DSOAL part that causes it, right?

[mirh]

If you could use the latest oal from here in your testing, it'd be great.
The biggest change between r422 and r430 was the one I mentioned above, which caused lots of regressions (and burden shifting) still being addressed.

[RavenMacDaddy]

The latest artifact at the time of writing works (CI #224: Commit cdd9a21), however still only with dsound.dll from r422.

[Kappa971]

Here is information about this game that I didn't know at all: https://www.pcgamingwiki.com/wiki/Claw
We are talking about a game from 1997, it is probably one of the first Windows games along with Road Rash, Earthworm Jim, Pitfall, Doom 95, ecc... What's the point of using DSOAL in these games? I doubt they have any kind of 3D audio nor EAX (the first Windows games I know to have EAX or/and 3D audio are Half Life and Unreal from 1998).

[mirh]

Yes, eax is a 1998 thing. So what?
Dsoal isn't just about.

DS3D could have been already potentially available in 1996 (even though miles doesn't mention it explicitly in the changelog until almost the end of the century). And since 1997 sound card quality mattered (it's so weird to quote wikipedia).

---

It's interesting to read on PCGW, that the game is alleged not to support surround sound (even though who knows how it was tested)
And that there's actually some whatever specifics "creative codecs" needed to run the dvd release.

[RavenMacDaddy]

I use it for Cubic spline resampling and the overall quality of the output.

Especially old games are rough as-is.

As for surround, that would be weird considering it's a 2D action platformer.

I think the DVD release was a promo thing from Creative with less compressed cutscenes, so surely they used some proprietary codecs to lock it down.

[mirh]

Yes you are right. It may or may not work already just with a MPEG-2 decoder actually, but this is outside the topic here.

[RavenMacDaddy]

Yes you are right. It may or may not work already just with a MPEG-2 decoder actually, but this is outside the topic here.

Sure is - just an interesting sidenote.

[Kappa971]

Yes, eax is a 1998 thing. So what?
Dsoal isn't just about.

mmh it definitely doesn't use DirectSound3D, probably just DirectSound (stereo audio, 2d) so, leaving out the higher quality resampling of DSOAL, it should work natively with Windows dsound.dll. It is however strange that there are some missing sounds with the latest versions of DSOAL, but i haven't tried this game.

DS3D could have been already potentially available in 1996 (even though miles doesn't mention it explicitly in the changelog until almost the end of the century). And since 1997 sound card quality mattered (it's so weird to quote wikipedia).

Before 1998 I believe that no game uses 3D audio, indeed until 1997 there were still games for DOS. Also, one of the first cards to support this (Sound Blaster Live!) came out in 1998.

[mirh]

https://www.gamecareerguide.com/features/sound_and_music/090597/direct_sound.htm
Even if it's just to run the dx3 samples it should be an objective.

[kcat]

Given that it works with r422, which was made Nov 1st 2021, and not the latest version, and it doesn't use EAX, there's only a couple commits that could've really broken it.

Commit f7ce1f0 adds partial support for the VoiceManager extension that some apps want. It's primarily a no-op, but if the game uses it and is sensitive to what it may return, it could be causing the app to get confused and not play certain sounds.

Commit e7a82d4 reduces the number of allocatable DSound buffers, from 256 "hardware" and 256 "software" buffers, to 128 of each. Some games didn't like having so many hardware voices, but if this game uses software buffers, it might be that 128 is too few. I don't know what native DSound does for the number of software buffers, but DSOAL might need the number of software buffers increased again.

[mirh]

#23 (comment) has build in-between the two points.
Speaking of the number of sources specifically instead, I remembered #28 (here they pitch 1024 to be the magic amount?)

[kcat]

Speaking of the number of sources specifically instead, I remembered #28 (here they pitch 1024 to be the magic amount?)

That seems to be referring to the number of OpenAL sources that can be created with their X-Fi card. Maybe that hints at the maximum number of DSound "software" buffers you could get with ALchemy (1024 total - 128 hw = 896 sw), or maybe it's unrelated and is just what they felt was good enough for OpenAL apps.

What's annoying is that OpenAL Soft could've had "infinite" (4 billion) sources and only limit the number to play as needed. But as the answer in the stackoverflow question says,

In practice if you're using a hardware based driver, just keep creating them until alGenSources fails.

For any apps that do that, there has to be a limit or else it can crash (if not hang the system from OOM). Even a really high default limit could cause memory waste if the app generates as many as it can but only uses a handful. So OpenAL sticks with the 256 default limit used by other implementations with the 'every source is playable' philosophy, and anything more needs to be requested by the app with the expectation it'll behave itself with the amount it asks to make.

That Guild Wars 1 issue may be a separate concern, since it doesn't actually play any of the software buffers it creates, so realistically it shouldn't need a source for them. Software buffers should probably handle sources more dynamically (get a source only when playing, give it back when not).

[kcat]

Commit e7bc895 increases the number of software buffers (to 384), which should help with this case.

[RavenMacDaddy]

Not noticing any issues with build 435a on here - closing.