SFML community forums
Help => Audio => Topic started by: Heliolater on April 12, 2016, 02:18:17 am
-
I've spent all day trying to solve this one myself, but I appear to lack the requisite knowledge. I've read the first 5 pages of this subforum and searched both here and extensively on stack and google, and dug through the tutorials and documentation. I'll give as much info as I know how to give and provide more on request.
So I have a piece of code that functions fine in an isolated project, but returns the following error when I close the window in the actual program.
Unhandled exception at 0x756ba4b9 in GameGraphics.exe: 0xC0000005: Access violation reading location 0xfeeefeee.
I am running the latest SFML version, 2.3.2 (32) for VS2010,
Visual Studio pops up this extra frame titled crtexe.c
Call Stack looks like this:
GameGraphics.exe!_tmainCRTStartup() line 568
GameGraphics.exe!mainCRTStartup() Line 371
Contents of the crtexe.c frame look like this:
if ( !managedapp ) //value 0
exit(mainret);
//--> if (has_cctor == 0)
_cexit();
}
Autos window looks like this:
has_cctor (Value 0)
mainret (Value 0)
Linker->Input looks like this:
sfml-audio-d.lib
sfml-network-d.lib
sfml-graphics-d.lib
sfml-window-d.lib
sfml-system-d.lib
All of the dlls from /bin are in the same directory as my executable. I have tried multiple downloads.
Minimum code sample:
#include <SFML/Audio.hpp>
#include <SFML/Graphics.hpp>
#include <string>
using namespace std;
class SFX {
private:
sf::Sound _sound;
sf::SoundBuffer _soundBuffer;
bool _initialized;
public:
void initialize(string fileName);
bool run();
SFX();
};
SFX::SFX() {
_initialized = false;
}
void SFX::initialize(string fileName) {
if(_soundBuffer.loadFromFile(fileName) ) {
_sound.setBuffer(_soundBuffer);
_initialized = true;
}
}
bool SFX::run() {
if( ! _initialized) {
//smartErr(__FUNCTION__,"NOT INITIALIZED");
return false;
}
//if(_sound.getStatus() == sf::Sound::Status::Playing) {
// return false;
//}
_sound.play();
return true;
}
class SoundService {
private:
public:
SFX sfxAttackBadMagic;
void initialize();
SoundService();
}soundServ;
SoundService::SoundService() {
}
void SoundService::initialize() {
sfxAttackBadMagic.initialize("Sounds/sfxAttackBadMagic.wav");
}
int main()
{
soundServ.initialize();
soundServ.sfxAttackBadMagic.run();
while(!sf::Keyboard::isKeyPressed(sf::Keyboard::Escape))
{
sf::sleep(sf::milliseconds(200));
}
return 0;
}
Notably, adding even this single line of code causes the same error:
sf::SoundBuffer testBuffer;
I've made all the changes and tried various changes, but nothing but removing the code solves the issue. Please help, you are my only hope.
-
Have you copied the OpenAL32.dll from the SFML SDK?
So you're saying that if you just create a sound buffer in int main thd application will crash at exit?
-
From the extracted SFML/bin, I have taken every file and copied them to the same directory as my executable. There included a file named openal32.dll I am certain.
And yes, simply declaring a sound buffer causes the exception when I close the window. Thank you for attending to this.
-
Update:
Just came back from vacation and decided to idiot-test the issue. I copied the text of my program into a new VS2010 project and set the project include and dependencies afresh. The only change I made this time was depositing my sound and texture files into their own folders, along with a number of text files, and map arrays, and deleting about half a thousand random files that look like VS logs of some kind.
The issue has disappeared for now, thankfully, as I quite like SFML. I was able to encapsulate the buffer and sound objects into a bundle, initialize them as a unit, and play the sound. (Does this seem like a reasonable way to handle sound effects that I don't want multiples of, assuming I need less than 256 individual sounds?)
I can't for the life of me figure out what the issue is, but apparently it wasn't the architecture. I'm... basically going to shrug it off and move on, unless anyone needs further reporting on the issue for whatever reason.
-
Could it be that the sound that is declared before the buffer is using the buffer when that buffer is destroyed? If so, declaring the buffer before the sound might help (you should probably do this anyway).
See SFML Audio Tutorial, "Playing Sounds" -> "Common Mistakes". (http://www.sfml-dev.org/tutorials/2.3/audio-sounds.php#common-mistakes)
-
I really don't think so. Back when I was testing I was getting the error just from declaring a soundbuffer, with no reference to a sound whatsoever. In addition, the exact same code worked perfectly with no errors on a fresh project. If I had to guess, I'd say there was a setting or a file set incorrectly, despite my zealous review.
Sometimes you just go code blind.
I will make sure that the encapsulating classes declare their buffer members before their sound members, assuming they get rid of them in that order when the object is destroyed. Thanks!
-
I will make sure that the encapsulating classes declare their buffer members before their sound members, assuming they get rid of them in that order when the object is destroyed. Thanks!
They should be declared first so that they are destroyed last.
I can't remember for sure but I think that the order you specify them in the initialisation list of a constructor can also affect this.
-
I really don't think so. Back when I was testing I was getting the error just from declaring a soundbuffer, with no reference to a sound whatsoever. In addition, the exact same code worked perfectly with no errors on a fresh project. If I had to guess, I'd say there was a setting or a file set incorrectly, despite my zealous review.
Sometimes you just go code blind.
I will make sure that the encapsulating classes declare their buffer members before their sound members, assuming they get rid of them in that order when the object is destroyed. Thanks!
Any update on the issue? I would really love to know. It seems I have the same problem with yours. I want this soundbuffer matter be resolved.
-
Issues like this are pretty much always a problem regarding the order of destruction (the sf::SoundBuffer is destroyed while the sf::Sound is still playing).
Maybe we could add debug only reference counting to print warnings if that happens.
So basically make sure all sf::SoundBuffer objects live longer than the sf::Sound objects using them.
Edit: Just checked and that problem shouldn't occur any longer. It might still be something with object lifetime though.