Jump to content
The Dark Mod Forums

Stuttering sound and performance loss when using OpenAL HRTF


MirceaKitsune

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)

  • Like 1
Link to comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
Share on other sites

  • 2 months later...
6 hours ago, stgatilov said:

@MirceaKitsune, please check the referenced GitHub thread.
@KCat asks for OpenAL log there...

How do I obtain that log? TDM doesn't generate it in the location suggested last time on Linux, there is no OpenALlog.txt or OpenAL.txt.

Edit 1: Sorry I see the variables I must use for it described there. I'll try to reproduce and post a log.

Edit 2: Posted the log from a run with the issue triggered, with a description encompassing what I said in this thread.

Edited by MirceaKitsune
Done
  • Thanks 1
Link to comment
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.

  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...