Splinter Cell: Chaos Theory (Versus) - In-game voice chat distortion

[Joshhhuaaa]

Note: For those unfamiliar with Splinter Cell: Chaos Theory, the Versus mode runs on a different executable and engine build than the Single Player/Coop modes, so they are not directly comparable.

The voice chat quality in this game, by today’s standards, is considered subpar, though it’s still okay enough to be understandable. We were hoping to improve the in-game voice chat quality in the future, as some players would prefer to use it over external programs such as Discord, due to how it’s integrated into the gameplay (proximity chat with the enemy, hacking into their communications, etc.).

There is a bug where players’ microphones sound completely distorted and unintelligible, and this seems to be linked to using DOSAL for EAX. I typically use ALchemy's dsound.dll to emulate EAX, which doesn’t break the voice chat in this game, so this appears to be a specific issue with DOSAL.

With DOSAL, both transmitting your own voice to players and hearing other players’ voices become distorted, making it impossible to understand each other (players without DOSAL will still hear your voice as distorted).

This is quite a random issue, but I thought I'd share. It could be helpful for Linux users on Chaos Theory Versus using EAX, as well as those who prefer DOSAL over Creative's implementation.

[ThreeDeeJay]

EnableLogDSOAL.zip

Log files might be helpful. you can drag the exe into this script to create them.

This reminds me to one of the Fallout games (New Vegas?) that lacked radio distortion, and GTA San Andreas used to crash because the Radio EQ used an unimplemented effect. So perhaps DSOAL is asked to process the voice audio before being sent over the internet and that hasn't been implemented? The discussion in kcat/openal-soft#415 might be relevant.
Have you checked if there's a way to disable any effects applied to the players' voices in a config file or something?

[Joshhhuaaa]

The batch file didn't work for me for some reason, so I ran these directly in command prompt within the game directory instead:

set DSOAL_LOGLEVEL=4
set DSOAL_LOGFILE=1_dsoal_log.txt
set ALSOFT_LOGLEVEL=3
set ALSOFT_LOGFILE=1_alsoft_log.txt
SCCT_Versus.exe

I've attached the log files below. I used the latest release from your repo as of now (DSOAL v0.9.7 + OpenAL Soft v1.24.2). I also tried the C++ rewrite earlier, but the voice chat didn't work at all, couldn't hear or speak.

1_dsoal_log.txt
1_alsoft_log.txt

Currently, the voice chat audio is limited to a 11020Hz sample rate, which you may notice as a conversion in the logs when it interacts with the recording device. I was thinking DOSAL might be listening to or transmitting your voice at 48000Hz, which could be causing distortion.

The original game defaulted to 8000Hz, but we managed to increase it to 11020Hz for a slight improvement. While we hope to improve it further, 11020Hz may be the highest we can achieve with the current capture method.

[kcat]

I also tried the C++ rewrite earlier, but the voice chat didn't work at all, couldn't hear or speak.

I just pushed some commits to the c++-rewrite branch to implement capture. Barring any bugs, that should work now.

[Joshhhuaaa]

I also tried the C++ rewrite earlier, but the voice chat didn't work at all, couldn't hear or speak.

I just pushed some commits to the c++-rewrite branch to implement capture. Barring any bugs, that should work now.

Thanks, I tried building the new C++ rewrite, and it seems to behave the same as the master branch now, where the voice sounds distorted and robotic.

[kcat]

Thanks, I tried building the new C++ rewrite, and it seems to behave the same as the master branch now, where the voice sounds distorted and robotic.

Can you make a DSOAL log with the updated rewrite branch?

[Joshhhuaaa]

Thanks, I tried building the new C++ rewrite, and it seems to behave the same as the master branch now, where the voice sounds distorted and robotic.

Can you make a DSOAL log with the updated rewrite branch?

I had set my mic to 11020Hz in Windows in these specific logs, as I was curious if it would fix the issue, since the game’s voice chat naturally records at 11020Hz. However, it didn’t help, voice was still distorted.

1_dsoal_log.txt
1_alsoft_log.txt

Edit: Here is another log with my mic set to 48000Hz if that matters:

1_dsoal_log.txt
1_alsoft_log.txt

[kcat]

I pushed a few more commits, which probably won't fix anything but will provide a bit more information in the log about the capture device. A new DSOAL log may help shed light on what it's doing.

Aside from that, are you able to make a recording of what the capture sounds like? Also, when you say "hearing other players’ voices become distorted", is that with them not using DSOAL or only when they do? That is, their voice sounds distorted and unintelligible when you're using DSOAL and they're not?

[Joshhhuaaa]

I pushed a few more commits, which probably won't fix anything but will provide a bit more information in the log about the capture device. A new DSOAL log may help shed light on what it's doing.

1_dsoal_log.txt
1_alsoft_log.txt

Aside from that, are you able to make a recording of what the capture sounds like?

Voice Chat example of hearing another player

Also, when you say "hearing other players’ voices become distorted", is that with them not using DSOAL or only when they do? That is, their voice sounds distorted and unintelligible when you're using DSOAL and they're not?

If you are using DSOAL, you essentially break communications both ways with everyone:

• A user without EAX will hear you as distorted.
• A user with ALchemy EAX will hear you as distorted.
• A user using DSOAL will hear you as distorted.

Additionally, you will hear everyone as distorted whether they have no EAX, ALchemy EAX, or DSOAL.

[kcat]

Okay, I think I found the problem with capture. I had the capture/read positions swapped so it was continually trying to read old data that was being overwritten. I pushed a commit to fix that.

However, I'm not sure what the problem is with you hearing everyone as distorted even if they don't use DSOAL. It wouldn't be a capture problem in that case since the audio is coming from a network connection rather than an audio capture device. If there's an issue hearing others, that would suggest a problem with playback buffer streaming, which does otherwise work. I'll need to look more into that.

[Joshhhuaaa]

Okay, I think I found the problem with capture. I had the capture/read positions swapped so it was continually trying to read old data that was being overwritten. I pushed a commit to fix that.

However, I'm not sure what the problem is with you hearing everyone as distorted even if they don't use DSOAL. It wouldn't be a capture problem in that case since the audio is coming from a network connection rather than an audio capture device. If there's an issue hearing others, that would suggest a problem with playback buffer streaming, which does otherwise work. I'll need to look more into that.

We’ve got an improvement with your new commit. Now, someone who is using ALchemy (or no EAX at all) can hear a DSOAL user speak clearly. The only remaining issue is that DSOAL's playback still has the same distorted effect, it only affects the person using DSOAL.

Some logs using this latest version if needed:
1_alsoft_log.txt
1_dsoal_log.txt

[kcat]

Looks like the playback issue is a bug in the game. It seems to be doing this when it gets a notification of more input audio:

1d14:debug:dsound:Buffer::GetCurrentPosition (0xf564620)->(0xfebff3c, 0xfebff28)
1d14:debug:dsound:Buffer::GetCurrentPosition pos = 284, write pos = 724
1d14:debug:dsound:Buffer::Lock (0xf564620)->(284, 440, 0xfebff30, 0xfebff2c, 0xfebff44, 0xfebff34, 0)
1d14:debug:dsound:Buffer::Unlock (0xf564620)->(0x1008e7c0, 440, 0x0, 0)
1d14:debug:dsound:DSCBuffer::GetCurrentPosition (0xf223f08)->(0xfebff3c, 0xfebf8ec)
1d14:debug:dsound:DSCBuffer::GetCurrentPosition  pos = 1284, read pos = 1064
1d14:debug:dsound:DSCBuffer::Lock (0xf223f08)->(624, 440, 0xfebff34, 0xfebf8e8, 0xfebff44, 0xfebff38, 0x0)
1d14:debug:dsound:DSCBuffer::Unlock (0xf223f08)->(0x100fed70, 440, 0x0, 0)

That is, it gets the streaming buffer's read and write positions, and writes between the last known write position up to the new write position from an internal buffer (then reads more audio from the input into its internal buffer). However, the docs are clear for the playback buffer positions:

The write cursor is the point in the buffer ahead of which it is safe to write data to the buffer. Data should not be written to the part of the buffer after the play cursor and before the write cursor.

(emphasis mine). But that's exactly what it's doing. The part of the buffer between the last known write pos to the current write pos necessarily includes the area after the play cursor and before write cursor, which must not be written to because that's being read for mixing. I'd expect a similar issue with the game in native, as I don't know how else DSound could behave that wouldn't break what the docs say (and indeed, looking at Wine, it seems to behaves as specified). Unless this isn't what the game normally does and something with DSOAL is causing it to misbehave, but I don't know what that could be.

[Joshhhuaaa]

I'm not sure how ALchemy manages to avoid issues when the game has a bug due to its poor implementation. We tried tweaking some audio variables, and while the distortion in DSOAL can be somewhat reduced, it can't be fully eliminated. Thanks for looking into the issue regardless.

I also wanted to ask if there's a known way to use ALchemy on Linux. A few people have tried, and it seems that DSOAL is currently the only solution for EAX on Linux. However, if ALchemy works, we'd likely switch to using it because of the voice chat issue in this particular game.

[ThreeDeeJay]

What happens when users try to use ALchemy on Linux?
Does it generate a dsoundlog.txt next to the dsound.dll? If so, what does it say?
I wonder if it would be a good idea to replace ALchemy's built-in software OpenAL library with OpenAL Soft
I managed to do it here #51 (comment)
Basically it just needs a Creative card supported by ALchemy (or Universal/Unlocker), rename the OpenAL Soft device to match the sound card's device name, and a dsound.dll patch to force loading ct_oal.dll/"Native OpenAL renderer) that we can rename soft_oal.dll to.