Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Error Generating OpenAL Hardware buffer when all audio devices are disabled #292

Closed
TommyHanusa opened this issue May 27, 2020 · 11 comments
Closed

Error Generating OpenAL Hardware buffer when all audio devices are disabled #292

TommyHanusa opened this issue May 27, 2020 · 11 comments

Comments

@TommyHanusa
Copy link

TommyHanusa commented May 27, 2020 •
edited
Loading

On Windows 10 64-bit disabling all audio devices will prevent maps from loading and an error will be generated.
stdout.txt

Repro steps:

  1. Disable all audio devices in settings>Manage Sound Settings.
  2. Launch Dhewm3 1.5.1pre and progress to the main menu.
  3. Start a new game with any difficulty.

Notes: using the console command "map mapname" will also generate an error.
@DanielGibson
Copy link
Member

DanielGibson commented May 27, 2020 •
edited
Loading

(Update: ah, much better :))

@TommyHanusa
Copy link
Author

What's audio device maps?
What operating system is that on? openal-soft or something else?
Also, having the actual error message and when exactly it happens (after starting the dhewm3 executable? when loading a map? ...) would be very helpful :)

Sorry, I fat fingered a submit on the bug.

@TommyHanusa
Copy link
Author

Lemme know if you can't get a repro.

@DanielGibson
Copy link
Member

Sorry, I fat fingered a submit on the bug.

no worries :)

I think I have an idea for a workaround (ok, two actually), but I gotta go to bed before I get around to implementing it (and building fresh Windows binaries for you to test).
I'll also try to reproduce it on Win10 (where do I disable audio devices? I rarely use Windows..), good to know there seems to be a generic way to do it - I don't have a bluetooth headset..

@TommyHanusa
Copy link
Author

I think I have an idea for a workaround
The work around is literally 'enable an audio device'.

I only found this issue because I was using a Bluetooth headset that would go into sleep mode and disconnect from my computer. Reconnecting a device solves the issue.

@DanielGibson
Copy link
Member

DanielGibson commented May 27, 2020 •
edited
Loading

No, I mean a workaround in the code ;)
On the one hand Doom3 without sound really sucks, but on the other hand it at least shouldn't crash and might be useful for testing..
It's just that right now the sound initialization code assumes that initializing openal eventually succeeds (if not with a user configured device then with a default device); I should check for this and disable sound if the default device also fails.
However, I'm not 100% sure disabling sound even is enough, if the game still tries to do things to openal that it doesn't like then I can make it use openal-softs "null" driver which just doesn't output any sound, but otherwise pretends to work. (UPDATE: One can't change the OpenAL driver after trying to initialize a context once - luckily it wasn't necessary as disabling sound worked).

DanielGibson added a commit that referenced this issue May 27, 2020
@DanielGibson
Disable sound if initializing OpenAL failed, fixes #292
208d94b 
idSoundSystemLocal::Init() didn't consider the case that opening the
default device (alcOpenDevice(NULL)) could fail, but this can happen if no
audio devices exist (or all are disabled or they're sleeping bluetooth
headphones or whatever).
Starting a map failed then with
  ERROR: idSoundCache: error generating OpenAL hardware buffer
Now this and "s_noSound 1" are handled the same and one can play.
DanielGibson added a commit that referenced this issue May 28, 2020
@DanielGibson
Disable sound if initializing OpenAL failed, fixes #292
0ccdb59 
idSoundSystemLocal::Init() didn't consider the case that opening the
default device (alcOpenDevice(NULL)) could fail, but this can happen if no
audio devices exist (or all are disabled or they're sleeping bluetooth
headphones or whatever).
Starting a map failed then with
  ERROR: idSoundCache: error generating OpenAL hardware buffer
Now this and "s_noSound 1" are handled the same and one can play.
@DanielGibson
Copy link
Member

DanielGibson commented May 29, 2020 •
edited
Loading

I think I fixed this issue, and also #209 and #291.
I created a build with all those fixes (and otherwise based on latest master), can you test it?
dhewm3-oal-fixes.zip
UPDATE: Please test the updated binaries from the pull request linked below instead.
Thanks in advance! :)

@DanielGibson
Copy link
Member

These fixes are in master, but I have another OpenAL related fix that needs testing, see #296

There you can also get Windows binaries for testing that include all the OpenAL fixes of the build linked above, the aforementioned timing fix and latest changes from master.

@TommyHanusa
Copy link
Author

Okay, I'll try to give this a look tonight.

@TommyHanusa
Copy link
Author

This is confirmed fixed.

@DanielGibson
Copy link
Member

Great, thanks for testing!

@singalen singalen mentioned this issue Dec 11, 2021
Closed
rorgoroth pushed a commit to rorgoroth/dhewm3 that referenced this issue Apr 8, 2023
@DanielGibson
Disable sound if initializing OpenAL failed, fixes dhewm#292
be05208 
idSoundSystemLocal::Init() didn't consider the case that opening the
default device (alcOpenDevice(NULL)) could fail, but this can happen if no
audio devices exist (or all are disabled or they're sleeping bluetooth
headphones or whatever).
Starting a map failed then with
  ERROR: idSoundCache: error generating OpenAL hardware buffer
Now this and "s_noSound 1" are handled the same and one can play.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@DanielGibson @TommyHanusa