SFML community forums

Help => Audio => Topic started by: Hapax on July 01, 2014, 05:01:41 am

Title: [SOLVED] Problems with .setPitch
Post by: Hapax on July 01, 2014, 05:01:41 am
This has been solved for my own errors although unsure of whether openal would cause anything else related.

Here's some code to test pitches (mine now works for all of these!):
#include <SFML/Audio.hpp>
#include <iostream>

int main()
{
        sf::SoundBuffer soundBuffer;
        if (!soundBuffer.loadFromFile("piano_a3.wav"))
                return -1;
        sf::Sound sound;
        sound.setBuffer(soundBuffer);
        for (float i{ 10 }; i <= 100; ++i)
        {
                std::cout << i << std::endl;
                sound.setPitch(i);
                sound.play();
                while (sound.getStatus() == sf::Sound::Playing) { }
        }
        return 0;
}


Here's the original post:
(click to show/hide)
Title: Re: Problems with .setPitch
Post by: select_this on July 01, 2014, 12:00:27 pm
Just did a preliminary test and I couldn't reproduce the crash (on Ubuntu 14.04) - everything worked as expected. Do you have a stack trace we can look at? It might be helpful if you attached the samples you used too.
Title: Re: Problems with .setPitch
Post by: Hapax on July 01, 2014, 01:36:51 pm
I forgot to mention that I'm using Visual Studio 2013 Express on Windows 7 64-bit. It suppose that it's possible that it could be Windows-related.

I've uploaded to Mediafire the exact sounds I used for this particular test (http://www.mediafire.com/download/kp39a3i3bul8cbh/SetPitchTestSounds.zip).
Title: Re: Problems with .setPitch
Post by: Laurent on July 01, 2014, 01:47:21 pm
Are you sure that you're using the OpenAL32.dll file of the SFML SDK, and not another one that would be installed in a default path (like Windows/System)?
Title: Re: Problems with .setPitch
Post by: select_this on July 01, 2014, 01:51:11 pm
I can confirm that none of your samples cause a crash on Linux, which does suggest your problem is pertaining to the platform-specific implementation.
Title: Re: Problems with .setPitch
Post by: Hapax on July 01, 2014, 01:54:33 pm
Are you sure that you're using the OpenAL32.dll file of the SFML SDK?
Yes. If I rename the openal32.dll file (from the SFML download) that is in the directory with the compiled program, it fails to run.
Title: Re: Problems with .setPitch
Post by: Hapax on July 01, 2014, 04:43:48 pm
I can confirm that none of your samples cause a crash on Linux, which does suggest your problem is pertaining to the platform-specific implementation.
I could be only happening on my setup rather than all Windows setups so if someone could test those samples with Windows, it would be a lot of help.

Has this problem arisen before? My SFML build is a couple of months old (it was the latest GitHub version at the time) and I was wondering if it had been fixed since then.
Title: Re: Problems with .setPitch
Post by: Hapax on July 01, 2014, 05:54:23 pm
The error that the debugger reports is:
Quote
Unhandled exception at 0x54382EB4 (openal32.dll) in PitchTest.exe: 0xC0000005: Access violation reading location 0x06C35000.

I downloaded a random sample and that particular sample does not cause these errors. I have even resaved the sample in the same format using the same software (Audacity) and it still doesn't cause the error. What does my openal32.dll have against these other samples?
Title: Re: Problems with .setPitch
Post by: Jesper Juhl on July 01, 2014, 08:07:52 pm
Just a few random guesses/sugestions that could perhaps bring you closer to figuring out what goes wrong:

- build SFML and openal yourself as debug builds. If you are lucky then sanity checks (asserts, range checks etc) in one of the libraries may trigger and provide a hint.

- do a build with a different compiler (like GCC) to perhaps get a different crash/stack trace with more/different details.

- do a GCC build with 'address sanitizer' enabled and hope that it catches something at runtime.

- do a build on Linux and run the executable through Valgrind and see if it reports anything.

- do a build of openal & SFML through 'clang analyze' and see if any of the stuff it reports looks relevant to your crash.

- ask on the openal mailing list if they have any ideas.

That's what I can come up with for now and is probably what I'd do in your situation. I hope it helps :)
Title: Re: Problems with .setPitch
Post by: Hapax on July 01, 2014, 08:27:33 pm
- build SFML and openal yourself as debug builds. If you are lucky then sanity checks (asserts, range checks etc) in one of the libraries may trigger and provide a hint.

- do a build with a different compiler (like GCC) to perhaps get a different crash/stack trace with more/different details.

- do a GCC build with 'address sanitizer' enabled and hope that it catches something at runtime.

- do a build on Linux and run the executable through Valgrind and see if it reports anything.

- do a build of openal & SFML through 'clang analyze' and see if any of the stuff it reports looks relevant to your crash.

- ask on the openal mailing list if they have any ideas.
This is all way beyond my skill level. Building SFML myself was difficult enough and I don't think even that went perfectly.

Do you have a stack trace we can look at?
Call Stack at time of debugger break:
>   openal32.dll!54b92eb4()   Unknown
    [Frames below may be incorrect and/or missing, no symbols loaded for openal32.dll]   
    openal32.dll!54b912c1()   Unknown
    openal32.dll!54b8911e()   Unknown
    openal32.dll!54b937e6()   Unknown
    openal32.dll!54b8d1ec()   Unknown
    [External Code]   
Title: Re: Problems with .setPitch
Post by: Jesper Juhl on July 01, 2014, 08:36:18 pm
Quote
Do you have a stack trace we can look at?
Call Stack at time of debugger break:
>   openal32.dll!54b92eb4()   Unknown
    [Frames below may be incorrect and/or missing, no symbols loaded for openal32.dll]   
    openal32.dll!54b912c1()   Unknown
    openal32.dll!54b8911e()   Unknown
    openal32.dll!54b937e6()   Unknown
    openal32.dll!54b8d1ec()   Unknown
    [External Code]
This would be a lot more useful if OpenAL, SFML & your app had been built with debug symbols ;)
Title: Re: Problems with .setPitch
Post by: Hapax on July 01, 2014, 08:39:20 pm
This would be a lot more useful if OpenAL, SFML & your app had been built with debug symbols ;)
It's really the first time I've tried to use the debugger ;D Never really had anything that needed debugging.
I don't know what debug symbols are... :(
Title: Re: Problems with .setPitch
Post by: Jesper Juhl on July 01, 2014, 08:52:55 pm
Quote
This is all way beyond my skill level.
Fair enough. However, there's no time like the present (and an actual problem) to learn new stuff. And trust me, being able to do the things I listed will be useful in the future. Might as well learn now :)

Quote
Quote
This would be a lot more useful if OpenAL, SFML & your app had been built with debug symbols ;)
It's really the first time I've tried to use the debugger ;D Never really had anything that needed debugging.
I don't know what debug symbols are... :(
Debug symbol (http://en.m.wikipedia.org/wiki/Debug_symbol)s are information that your compiler can insert into the compiled object files/binaries that make it possible to work backwards from the machine-code to the original source file(s). Debugging without them is of course possible, but a lot harder and usually requires you to know some asm for your target platform - when debugging something you usually want a non-optimized build with debug symbols or you are going to have a huge challenge ahead of you compared to what you could have.
Title: Re: Problems with .setPitch
Post by: Hapax on July 01, 2014, 11:49:55 pm
Might as well learn now :)
I'd like to rebuild SFML to include the debugging libraries but I'm worried that if I risk attemping it again and fail, I could cause it SFML to not work at all whereas it currently works without the debugging.

Quote
[Interesting and useful information about Debug symbols (http://en.m.wikipedia.org/wiki/Debug_symbol)]
I did wonder what that .PDB file was  ;D
I stopped trying to use the debugger when I realised that I didn't manage to build SFML with the debugger libraries and didn't know how to fix that.
Title: AW: Problems with .setPitch
Post by: eXpl0it3r on July 02, 2014, 08:27:07 am
You can still use my nightly builds if you'd break your SFML setup. ;)
Title: Re: AW: Problems with .setPitch
Post by: Hapax on July 04, 2014, 12:34:45 am
use my nightly builds
Thanks a lot, eXpl0it3r!
I think this might be the answer. I wanted to avoid getting someone else to do the build if I could just do it myself but, since I've been failing, I can't see that I should not use pre-built versions. Am I right in thinking that it's probably best to use the 32-bit build even though I'm using a 64-bit operating system?
Title: AW: Re: AW: Problems with .setPitch
Post by: eXpl0it3r on July 04, 2014, 08:09:39 am
Am I right in thinking that it's probably best to use the 32-bit build even though I'm using a 64-bit operating system?
If you have a 64 bit compiler as well it doesn't really matter. The only advantage 32 bit applications have, is that will also run on 32 bit platforms whose number keep dropping further every month. ;)
Title: Re: AW: Re: AW: Problems with .setPitch
Post by: Hapax on July 07, 2014, 11:41:03 pm
If you have a 64 bit compiler...
I'm using your nightly build and can now use debugging libraries and also use both 32-bit and 64-bit :)

Stepping through the Pitch Test application (with sound.setPitch(50); uncommented), it plays the sound when it moves from the while (window.pollEvent(event)) line to the if (event.type == sf::Event::Close) line, but still crashes if it is run without stepping, both debugging and not.

As for symbols, the problem area seems to be openal32.dll as it "was not built with debug information".
Title: Re: Problems with .setPitch
Post by: Hapax on September 18, 2014, 04:02:10 am
I stumbled upon the reason that I was getting this error. I'm still not sure why but it's easy enough to avoid for myself now.
I changed the sound settings for my audio interface to use 48kHz instead of 44.1kHz and it crashes on no pitches now. Fully updated the audio interface drivers beforehand to make sure of everything but it still crashes on 44.1, 16-bit and 24-bit. None of the higher frequencies cause the problem, it seems.
If you happen to get a similar problem, try changing those settings.

Hopefully, nobody will ever be using the same audio interface as me, running at 44.1kHz when trying to run something linked to openal  ;D

I've updated the original post to show that it has been solved and also included a shorter pitch testing code.