Jump to content
The Dark Mod Forums

Stuttering sound and performance loss when using OpenAL HRTF


Recommended Posts

https://bugs.thedarkmod.com/view.php?id=5292

Enabling the new OpenAL HRTF feature causes the sound to shutter (break up) to the point of becoming just random noises, while even graphical performance will stutter if starting up a game. If you wait for roughly 1 second to 1 minute, the issue eventually goes away and you start hearing sound normally as well as getting acceptable performance... the problem does however occur at every startup when that option is enabled.

TDM 2.08 (x64) on Linux openSUSE Tumbleweed (amdgpu / MESA)

Link to post
Share on other sites

The usual questions are:

  1. Is there anything suspicious in OpenAL log?
  2. Does the issue happens on other OpenAL backends?

Here is how I enable OpenAL logs on Windows:

set ALSOFT_LOGLEVEL=3
set ALSOFT_LOGFILE=openal_log.txt
TheDarkModx64.exe

The backends can be specified in alsoft.ini. Uncomment the line drivers = ...
I think possible values are: oss, pulse, jack, port, alsa

Link to post
Share on other sites

Never had this particular issue with any other game and its audio. The 32bit engine does the exact same thing as the 64bit one. I looked in Darkmod.log, the in-game console, and the bash console when running the engine from it: There's one suspicious message which appears to be spammed countless times among other normal messages.

AL lib: (EE) ALCplaybackAlsa_mixerNoMMapProc: available update failed: Broken pipe

The other stuff sounds a bit more complicated to toy with at the moment, especially as I'm not sure where the OpenAL log is located or how to enable it on Linux (the console variables might be different).

Edited by MirceaKitsune
Link to post
Share on other sites
Quote

AL lib: (EE) ALCplaybackAlsa_mixerNoMMapProc: available update failed: Broken pipe

The environment variables are the same on Linux.

Could you somehow monitor the openal_log.txt file and see if the cited messages correlate with your problems?
I.e. that all these messages are posted when you start game, continue while you have problems, and stop when the game starts working properly.
As far as I know, they mean that sound stream is not filled fast enough, and it can cause sound glitches and lags.

Link to post
Share on other sites
  • 2 weeks later...
On 7/12/2020 at 5:38 PM, stgatilov said:

The environment variables are the same on Linux.

Could you somehow monitor the openal_log.txt file and see if the cited messages correlate with your problems?
I.e. that all these messages are posted when you start game, continue while you have problems, and stop when the game starts working properly.
As far as I know, they mean that sound stream is not filled fast enough, and it can cause sound glitches and lags.

I couldn't find a separate openal_log.txt which makes sense since it's seemingly mixed with the realtime console output. I looked more carefully to make sure and indeed: The broken pipe messages are spammed constantly while the sound is crippled, but disappear the moment the audio fixes itself.

  • Like 1
Link to post
Share on other sites

There's not a lot of info on this error out there, but from what I could find it's likely to do with either openal itself, or with glibc.

This one related to openal: https://github.com/unrealarena/unrealarena/issues/30

And this one related to glibc: https://developer.blender.org/T49208

These are from around 2015/2016, so I don't think they'll help much.

  • Like 2

System: Mageia Linux Cauldron, aka Mageia 8

Link to post
Share on other sites

I get issues with sound on my computer if I set the sound card to anything higher than 44,100 audio.

Happens on both windows 7 and windows 10. Using a Creative Sound BlasterX AE5 card. 16 bit and 24bit and 32bit work fine though, just can't do more than 44,100.

I always assumed I'd taste like boot leather.

 

Link to post
Share on other sites
  • 3 months later...

Still dealing with this issue and it's becoming a huge annoyance, would greatly appreciate a suggestion against it! Most of the time when I start up TDM, I have to wait between 10 seconds and 1 minute for the sound shuttering and slowdowns to stop, everything is unplayable while this goes on. There must be some setting related to the buffer or something that is behind it. What do you suggest toying with in the settings for starters?

Link to post
Share on other sites
1 hour ago, lowenz said:

Meanwhile OpenAL Soft 1.21 is out ;)

And what's the point in all these updates if every version has its own bugs?
I think we have tried 1.18.2, 1.19.0 and 1.19.1, and none of them was issue-free.

 

  • Like 2
Link to post
Share on other sites
10 hours ago, stgatilov said:

I suggested trying other OpenAL backends. Maybe it is backend-specific.

How did I miss that? I just tried it but apparently there were no changes, neither value affects the issue. I'm fairly certain some options there should have stopped the audio from working at all though, so maybe alsoft.ini is ignored? It's an ini file after all, those are usually for Windows not for Linux.

Digging through my notes from back when I had sound issues with the 32-bit engine (RIP at long last) it seems I was able to add "seta s_driver oss" to Darkmod.cfg instead. However I just tried this now and even when I set s_driver to all of those values nothing happens. To my surprise, if I don't attempt to set the cvar at all but check its default value, s_driver is now seen as unknown when I type it into the console o_o

s_device is there though. It defaults to "default". I tried changing it but this does nothing either. I also used tab to look at the other cvars beginning with s_ but nothing relevant jumped to my attention... surprised there's nothing about the buffer length which is where I suspect this might be coming from.

Link to post
Share on other sites
34 minutes ago, MirceaKitsune said:

How did I miss that? I just tried it but apparently there were no changes, neither value affects the issue. I'm fairly certain some options there should have stopped the audio from working at all though, so maybe alsoft.ini is ignored? It's an ini file after all, those are usually for Windows not for Linux.

Oh, crap! Yes, it is alsoft.conf on Linux if you place it near executable.
There are some other paths also, and some of them probably have higher priority. You can check the openal_log.txt: it should show where it looks for config file and where it finds it.

Quote

Digging through my notes from back when I had sound issues with the 32-bit engine (RIP at long last) it seems I was able to add "seta s_driver oss" to Darkmod.cfg instead. However I just tried this now and even when I set s_driver to all of those values nothing happens. To my surprise, if I don't attempt to set the cvar at all but check its default value, s_driver is now seen as unknown when I type it into the console o_o

The s_driver is remnant of pre-OpenAL sound, it should have no effect right now.

Quote

s_device is there though. It defaults to "default". I tried changing it but this does nothing either.

This setting is used: it selects the sound device to use. E.g. if you have headphones and speakers, you can specify which one to use.
But it cannot change OpenAL backend.

Quote

surprised there's nothing about the buffer length which is where I suspect this might be coming from.

It is buried deeply inside OpenAL and quite likely cannot be controlled by application at all.

But perhaps it can be controlled by the ini file. At least I see buffer-size setting for jack backend there.
There are also period_size and periods which are somehow related to buffering.

 

Link to post
Share on other sites

Ah yes: Copying alsoft.ini to an alsoft.conf makes the changes there matter. I've been playing around with some of the settings now.

So if I use anything other than "drivers = alsa" I get no sound. ALSA seems to be the only one it will work with, or the others need to be further set up.

Preliminary testing shows some great news: I may have found the culprit! The issue appears to go away once I set "period_size = 64". Going at the other end, "period_size = 8192" also doesn't seem to do it oddly, but that causes a huge delay for all sounds. The issue is when I set it to a middle value like "period_size = 1024" to "period_size = 4096", that's what seems to cause it almost constantly... the distortions differ slightly based on this value. I can even add other improvements like "frequency = 48000" and it works!

I'll update if I still encounter it with these changes too. In the meantime please consider if based on this results, it might be a good idea to change the default value of period_size to something lower, seeing how this helps solve the problem. Any reason why it can't be 64 by default? The problem only seems to occur from 512 (very rare and brief then) and up (almost always starting from 1024), even a 256 should be safe if a slightly higher default is needed for other reasons.

Edited by MirceaKitsune
  • Like 2
Link to post
Share on other sites
15 hours ago, MirceaKitsune said:

In the meantime please consider if based on this results, it might be a good idea to change the default value of period_size to something lower, seeing how this helps solve the problem. Any reason why it can't be 64 by default? The problem only seems to occur from 512 (very rare and brief then) and up (almost always starting from 1024), even a 256 should be safe if a slightly higher default is needed for other reasons.

I won't do it.
I am far less competent in OpenAL that the OpenAL developer. I think he knows better what he is doing.

It sounds like buffering is not synchronized properly, causing holes occasionally.
How many CPU cores do you have? If it is too low, maybe sound thread is not executed as frequent as it needs (something else has high priority).

Link to post
Share on other sites
8 minutes ago, stgatilov said:

I won't do it.
I am far less competent in OpenAL that the OpenAL developer. I think he knows better what he is doing.

It sounds like buffering is not synchronized properly, causing holes occasionally.
How many CPU cores do you have? If it is too low, maybe sound thread is not executed as frequent as it needs (something else has high priority).

Sure. Just please contact the OpenAL dev (I don't know who he is) to ensure he sees this thread and is aware of the problem and my new results.

And I now have a Ryzen 7 3700X CPU which means 8 cores and 16 threads @ 3.6 GHz to 4.4 GHz.

Link to post
Share on other sites
On 11/11/2020 at 8:17 AM, stgatilov said:

Oh, crap! Yes, it is alsoft.conf on Linux if you place it near executable.

OMG no wonder changes to the .ini didn't do a damn thing. LOL. Maybe now I can get the sound working when the s_device is "default" instead of the named card.

  • Like 1

System: Mageia Linux Cauldron, aka Mageia 8

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...