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.

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

Error Generating OpenAL Hardware buffer when all audio devices are disabled

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

Comments

@TommyHanusa
Copy link

TommyHanusa commented May 27, 2020

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

(Update: ah, much better :))

@TommyHanusa
Copy link
Author

TommyHanusa commented May 27, 2020

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

TommyHanusa commented May 27, 2020

Lemme know if you can't get a repro.

@DanielGibson
Copy link
Member

DanielGibson commented May 27, 2020

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

TommyHanusa commented May 27, 2020

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

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
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
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

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

DanielGibson commented Jun 1, 2020

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

TommyHanusa commented Jun 2, 2020

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

@TommyHanusa
Copy link
Author

TommyHanusa commented Jul 19, 2020

This is confirmed fixed.

@DanielGibson
Copy link
Member

DanielGibson commented Jul 20, 2020

Great, thanks for testing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants