openal-soft
openal-soft copied to clipboard
kcat
KOTOR/KOTOR 2 - EAX Reverb gainhf out of range
When running the KOTOR games through openal-soft (using dsoal), and using EAX 2 or 3, I get repeated "EAX Reverb gainhf out of range" errors, and with EAX 3, I also get "EAX Reverb gainlf out of range" errors. EAX 1 does not have the error, and of course EAX disabled does not either. Logs for all four modes: No EAX: https://pastebin.com/HkTSTDTW EAX 1: https://pastebin.com/cKDpX3gp EAX 2: https://pastebin.com/a3GVEYWh EAX 3: https://pastebin.com/juxPJr7j While I can use EAX outside of OALSoft through Creative ALchemy, the lack of logging there makes it impossible for me to tell if this is a problem inherent to the game's EAX implementation.
This is more than likely a problem on DSOAL's side. DSOAL doesn't validate all the reverb parameters when converting and calling OpenAL with them since I haven't found documentation on how it should behave; whether it should return failure trying to set invalid parameters, whether the values get clamped to the valid range (and whether that clamp is implicit or explicit), or whether individual invalid values are ignored. Currently it's effectively ignored, and has OpenAL Soft print that warning.
While I can use EAX outside of OALSoft through Creative ALchemy, the lack of logging there makes it impossible for me to tell if this is a problem inherent to the game's EAX implementation.
I stumbled upon this post [1] describing some logging options for ALchemy. I don't have a Windows PC to test but maybe it's worth a try.
[1] https://www.vogons.org/viewtopic.php?p=870190#p870190
I'm curious if there's any updates for this. OpenAL Soft has native EAX API support on Windows now, and DSOAL has been changed to use it. Is the behavior any better? If there are problems, can you provide DSOAL and OpenAL Soft logs?
I'm curious if there's any updates for this. OpenAL Soft has native EAX API support on Windows now, and DSOAL has been changed to use it. Is the behavior any better? If there are problems, can you provide DSOAL and OpenAL Soft logs?
In KOTOR there are two errors about Room HF out of range and Property buffer too small.:
KOTOR2 seems does not use EAX at all.
Tested on GOG versions.
kotor1_alsoft_dsoal_logs_202304032214.zip
Well that's interesting.
[ALSOFT] (EE) EAXSet [EAX_REVERB_EFFECT] Room HF out of range (value: 1062501089; min: -10000; max: 0).
[ALSOFT] (EE) EAXSet [EAX_REVERB_EFFECT] Room LF out of range (value: 1065353216; min: -10000; max: 0).
[ALSOFT] (EE) EAXSet [EAX_REVERB_EFFECT] Room HF out of range (value: 1062501089; min: -10000; max: 0).
[ALSOFT] (EE) EAXSet [EAX_REVERB_EFFECT] Room LF out of range (value: 1065353216; min: -10000; max: 0).
1062501089 is 0.83f, and 1065353216 is 1.0f. The corresponding lines in the dsoal log are:
109c:trace:dsound:DSBufferProp_Get (00A379FC)->(DSPROPSETID_EAX30_ListenerProperties, 0x6, 00000000, 0, 0019FC08, 4, 0019FC0C)
109c:trace:dsound:DSBufferProp_Set (00A379FC)->(DSPROPSETID_EAX30_ListenerProperties, 0x6, 00000000, 0, 0019FC14, 4)
109c:trace:dsound:DSBufferProp_Get (00A379FC)->(DSPROPSETID_EAX30_ListenerProperties, 0x7, 00000000, 0, 0019FC08, 4, 0019FC0C)
109c:trace:dsound:DSBufferProp_Set (00A379FC)->(DSPROPSETID_EAX30_ListenerProperties, 0x7, 00000000, 0, 0019FC14, 4)
(the lack of a CommitDeferredSettings call after the DSBufferProp_Set is a giveaway that the EAXSet call failed). For some reason, it's reading the existing values but then trying to set float gain values when it should be long millibels.
The Property buffer too small error is a result of
109c:trace:dsound:DSBufferProp_Set (00A37AFC)->(DSPROPSETID_EAX30_BufferProperties, 0x2, 00000000, 0, 0019F9FC, 4)
109c:trace:dsound:DSBufferProp_Set (00A37AFC)->(DSPROPSETID_EAX30_BufferProperties, 0x4, 00000000, 0, 0019F9FC, 4)
trying to set the EAXSOURCE_OBSTRUCTIONPARAMETERS and EAXSOURCE_EXCLUSIONPARAMETERS properties with a 4-byte value, but those are expecting 8-byte EAXOBSTRUCTIONPROPERTIES and EAXEXCLUSIONPROPERTIES structs.
I've been doing some testing running Star Wars KOTOR under wine, with openal-soft and dsoal installed and configured in the wine prefix to allow EAX to be enabled in the game. I have the same issue, no errors logged with EAX 1 enabled, but the same 'Room HF/LF out of range' / 'buffer too small' errors with EAX 2 or 3 enabled. The issue for me is that it causes noticeable stuttering in gameplay when these errors are being triggered (can be easily felt when playing, and can be clearly seen in the mangohud frame time chart).
trying to set the EAXSOURCE_OBSTRUCTIONPARAMETERS and EAXSOURCE_EXCLUSIONPARAMETERS properties with a 4-byte value, but those are expecting 8-byte EAXOBSTRUCTIONPROPERTIES and EAXEXCLUSIONPROPERTIES structs.
Despite the structs being 8-byte, if the games are sending 4-byte values, then by looking at the structs definition, my guess is partial 4-byte update for the 1st long type parameter of the structs should be allowed while retaining the float ratios. This should have fixed the 'buffer too small' errors.
Despite the structs being 8-byte, if the games are sending 4-byte values, then by looking at the structs definition, my guess is partial 4-byte update for the 1st
longtype parameter of the structs should be allowed while retaining the float ratios. This should have fixed the'buffer too small'errors.
The question is if that's supposed to happen. It could be the game is just buggy with EAX, trying to set invalid parameters that effectively no-op, and accepting them would cause it to sound wrong by changing parameters to unintended values. It would need testing on real devices, as accepting values that should return an error could cause different problems.
Despite the structs being 8-byte, if the games are sending 4-byte values, then by looking at the structs definition, my guess is partial 4-byte update for the 1st
longtype parameter of the structs should be allowed while retaining the float ratios. This should have fixed the'buffer too small'errors.The question is if that's supposed to happen. It could be the game is just buggy with EAX, trying to set invalid parameters that effectively no-op, and accepting them would cause it to sound wrong by changing parameters to unintended values. It would need testing on real devices, as accepting values that should return an error could cause different problems.
Thank you (and @kjliew) for following up. While it wouldn't surprise me if the game was buggy with it's EAX code, in the past couple of years I have run game on my WinXP box in EAX 3 mode with 3 different Creative sound cards - an X-Fi XtremeGamer, an X-Fi Titanium and an Audigy 2 ZS, all with the official Creative driver packs.
I have been copying the save files across so I'm at the same in-game location, and I have not noticed anything off with the sound on my WinXP box.
I would like to suggest that they aren't invalid parameters by just updating the long part of the structs. You just don't touch the float ratios at all. I believe the float ratios have initialized default values and they don't require frequent updates as the long parameters. It may still be valid to clamp the long parameters if their ranges are defined in the spec.