next »

[Deckhead]

I struggled with understanding how to load and stream .ogg files with OpenAL and C++. Now that I've figured it out, I thought I'd write the tutorial that I wish I had.

https://indiegamedev.net/2020/01/16/how-to-stream-ogg-files-with-openal-in-c/

If there's any other audio related things that people struggle with, I'd like to know what they are so I can write about them if I've already solved it (or help figure it out if I haven't).

[Daid]

Would be interested in knowing how to prevent OpenAL from crashing. OpenAL is being used by SFML for audio output, and it's been a source of random crashes for some people. But only in like 1 in 20 people. This is with the OpenAL soft implementation, not sure if there are others.

[Deckhead]

Would be interested in knowing how to prevent OpenAL from crashing. OpenAL is being used by SFML for audio output, and it's been a source of random crashes for some people. But only in like 1 in 20 people. This is with the OpenAL soft implementation, not sure if there are others.

I've been using SFML and OpenAL Soft directly for the above without any issue. I know there was a version used by SFML previously that caused me problems (a few years ago) but recent versions of SFML have worked fine. Mind you, I build SFML myself and OpenAL Soft myself, have you tried that, building it all yourself?

[Daid]

Yeah, tried building it all myself, still crashes for a few players. Only solution so far has been to fully disable sounds/music. And it is really annoying, because it isn't very reproducible.

For newer stuff I've switched to SDL2. But the project where I have SFML and these crashes is too interwined with SFML to switch.

Oh, and I switched to stb vorbis: https://github.com/nothings/stb/blob/master/stb_vorbis.c
Instead of pulling the whole libvorbis as a dependency for ogg playback.

[Deckhead]

Yeah, tried building it all myself, still crashes for a few players. Only solution so far has been to fully disable sounds/music. And it is really annoying, because it isn't very reproducible.

Have you raised an issue on the SFML forums of github? What Operating System are you targetting?

For newer stuff I've switched to SDL2. But the project where I have SFML and these crashes is too interwined with SFML to switch.

Oh, and I switched to stb vorbis: https://github.com/nothings/stb/blob/master/stb_vorbis.c
Instead of pulling the whole libvorbis as a dependency for ogg playback.

I guess that the question I have that comes up is whether you know the crash is related to ogg playback or is it definitely a crash occurring in OpenAL? Are you using the latest version of OpenAL Soft?

I had problems with OpenAL Soft previously, and upgrading solved it. If you have something like Dr Memory available to use, I'd give that a go, as so many crashes are memory related, you might find something in there. If you have a debug build of OpenAL Soft as well, you could even trace a potential error into OpenAL Soft and fix it at the source.

[Daid]

Have you raised an issue on the SFML forums of github? What Operating System are you targetting?

I did raise an issue, no response really, I guess because the occurance is so rare they see it as a fluke, or that I am doing something wrong. This is on Windows, on linux it's rock solid. But the crash clearly happens in OpenAL according to the stack trace it's in an OpenAL thread, not in an API call. And the SFML use of the API looks all ok.

I guess that the question I have that comes up is whether you know the crash is related to ogg playback or is it definitely a crash occurring in OpenAL? Are you using the latest version of OpenAL Soft?

I switched to a latest greatest once. Then crashes happened for everyone, so switched back to a specific version.
Crashes are happening in OpenAL. As they also happen if music is disabled but only sound effects are playing.


I just gave up on it. I do not want to debug a large OpenAL stack. SDL2 is serving me a whole lot better then SFML these days.

[Deckhead]

I'm still super curious because I do have a memory leak coming out of OpenAL Soft's .dll on application shutdown. I'm using 1.19 but version 1.2 is out now which has probably fixed a lot of things.

But hey, if SDL is working for you, it's no big deal I guess.

[Daid]

Oh, yes, no big deal for me anymore. Just letting you know my experiences with it.

Also, I had a problem where some other application installed an openal32.dll in windows/system32, which was had an outdated API. And windows decided that that was a better fit that the one next to the executable.

[Deckhead]

Oh, yes, no big deal for me anymore. Just letting you know my experiences with it.

Also, I had a problem where some other application installed an openal32.dll in windows/system32, which was had an outdated API. And windows decided that that was a better fit that the one next to the executable.

That can't be right? Doesn't Windows use a local dll before looking in system 32? The names need to match I think, and that one you listed isn't openalsoft.

[Daid]

Not always, search order can be influenced.
https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

I don't remember the exact name of the dll, this was a few years ago. But the crash log included the full path to the dlls. And it was not using the one from my application, but from system32

[Deckhead]

Not always, search order can be influenced.
https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

I don't remember the exact name of the dll, this was a few years ago. But the crash log included the full path to the dlls. And it was not using the one from my application, but from system32

I stand corrected. I assume something you linked to would have changed the search order... but that's just such an odd thing for a library to want to do.