SFML community forums
Help => Audio => Topic started by: slotdev on November 11, 2014, 04:08:11 pm
-
Hi
OK, another crazy problem. I have a whole load of 2nd hand rack servers coming my way which I'll be using to do automated play-testing of games. Don't ask why...it's a long and painful story :(
Anyway, these units have no sound hardware at all. Starting the game will result in a crash as soon as sounds are initialised. So, how can I stop this happening?
Many Thanks
-
Have you found out where they crash exactly?
What are your options regarding the choice of SFML versions?
-
It crashes when trying to create a new sf::Music instance. Plugging in some USB sound hardware fixes it, but that's not an option for a rack of 20 machines :D
We are using quite an old version of SFML (09/10/2011!) but will be updating to the latest in Jan 2015.
Such is legacy support for applications...
-
By "where they crash exactly" I suppose Nexus meant, if you have a stack trace when the application crashes. :D
-
Yeah that's kind of the problem, I can't get a stack trace from this unit - it's not got any development tools on it, it is literally just a rack server PC running W7 Pro 64 bit, with a Radeon 5850 and that really is it.
-
Why dont you then either install a debugger on the machine or configure Windows to write a minidump when the app crashes that you can then inspect in a debugger on your normal dev machine?
-
I assume you're not able to change the source code so that it doesn't use music for testing purposes?
And if you can't change the SFML version before January, I don't see how we could possibly help... Even if we wrote a workaround, you couldn't make use of it. Not to mention the amount of experimenting it takes (including debugging), and the difficulty (impossibility?) to reproduce that problem on our machines :-\
-
I'm not sure, but maybe there are something like dummy drivers, so the server thinks it has an audio device, but it in fact doesn't?
-
Sounds like an OpenAL context couldn't be created and when we try to call any function it just segfaults (basically same like calling an uninitialized GL extension). Like the others have said, if you can't make any changes to the environment it's going to be hard to fix the problem. The easiest "solution" I can think of that doesn't involve altering the environment is to create stub classes with the same interface as the audio classes and switch them out with a TEST_WITHOUT_SOUND flag if you really have to test on those machines often.
-
Thanks for all the advice guys, some real help there :) I'm going to try and install a dummy audio device first and see what happens, if not, then I'll try stubbing out the sf::Audio stuff.
Thanks!