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

Bugfix/541 osx openal threadsafety #831

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
7 participants
@Ceylo
Contributor

Ceylo commented Mar 16, 2015

Provides OpenAL-soft 1.16 instead of OS X's OpenAL which is buggy.

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Mar 16, 2015

Member

Are 7 commits really necessary to change 6 files? 😁

https://ariejan.net/2011/07/05/git-squash-your-latests-commits-into-one

Then push using a force push (only do it for this purpose, none other!).

Member

binary1248 commented Mar 16, 2015

Are 7 commits really necessary to change 6 files? 😁

https://ariejan.net/2011/07/05/git-squash-your-latests-commits-into-one

Then push using a force push (only do it for this purpose, none other!).

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Mar 17, 2015

Member

Actually, I forgot about the templates... Could you change those two lines by the following and remove this comment?

            for f in "FLAC" "ogg" "vorbis" "vorbisenc" "vorbisfile" "OpenAL"

Thanks :-)

Beside that, this works great! So once this extra change is committed and everything is squashed it's all good for merge.

Member

mantognini commented Mar 17, 2015

Actually, I forgot about the templates... Could you change those two lines by the following and remove this comment?

            for f in "FLAC" "ogg" "vorbis" "vorbisenc" "vorbisfile" "OpenAL"

Thanks :-)

Beside that, this works great! So once this extra change is committed and everything is squashed it's all good for merge.

@mantognini mantognini removed the s:undecided label Mar 17, 2015

@mantognini mantognini added this to the 2.3 milestone Mar 17, 2015

@Ceylo

This comment has been minimized.

Show comment
Hide comment
@Ceylo

Ceylo Mar 17, 2015

Contributor

Hmm ok. However what is the link between this pull request and the comment you want me to remove?

Contributor

Ceylo commented Mar 17, 2015

Hmm ok. However what is the link between this pull request and the comment you want me to remove?

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Mar 17, 2015

Member

Oh, they are simply useless; the next statements are really obvious so... Two birds with one stone. :)

Member

mantognini commented Mar 17, 2015

Oh, they are simply useless; the next statements are really obvious so... Two birds with one stone. :)

@Ceylo

This comment has been minimized.

Show comment
Hide comment
@Ceylo

Ceylo Mar 18, 2015

Contributor

I hope I didn't forget anything now :D

Contributor

Ceylo commented Mar 18, 2015

I hope I didn't forget anything now :D

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Mar 18, 2015

Member

I was thinking of removing both comments but that's really not important and since it works well for me, let's move on and merge it! :-)

Member

mantognini commented Mar 18, 2015

I was thinking of removing both comments but that's really not important and since it works well for me, let's move on and merge it! :-)

@robertmassaioli

This comment has been minimized.

Show comment
Hide comment
@robertmassaioli

robertmassaioli Mar 21, 2015

So this is hitting me too on OSX. This issue has been going on for a while. I'm experiencing it too. I can also confirm that simply trying to open one file with SFML results in a crash every single time I run my program:

* thread #6: tid = 0x0005, 0x000000010497808d OpenAL`OALSource::RemoveBuffersFromQueue(unsigned int, unsigned int*) + 473, stop reason = signal SIGSTOP
  * frame #0: 0x000000010497808d OpenAL`OALSource::RemoveBuffersFromQueue(unsigned int, unsigned int*) + 473
    frame #1: 0x000000010496c77d OpenAL`alSourceUnqueueBuffers + 441
    frame #2: 0x0000000104934cb9 libsfml-audio.2.2.0.dylib`sf::SoundStream::clearQueue() + 109
    frame #3: 0x0000000104934298 libsfml-audio.2.2.0.dylib`sf::SoundStream::streamData() + 1260
    frame #4: 0x000000010495acae libsfml-system.2.2.0.dylib`sf::priv::ThreadImpl::entryPoint(void*) + 26
    frame #5: 0x00007fff8aeea899 libsystem_pthread.dylib`_pthread_body + 138
    frame #6: 0x00007fff8aeea72a libsystem_pthread.dylib`_pthread_start + 137
    frame #7: 0x00007fff8aeeefc9 libsystem_pthread.dylib`thread_start + 13

The original issue (#541) was from March 2 last year, meaning that this issue has been going on now for about one year and one month. Would be great if we could fix this. Would really help with an app that I am writing that I hope to have depend on SFML.

In the meantime I'm going to try my code out on Linux just to make sure that this issue is OSX specific. Also, I'll try and check out this branch and see if it works on OSX.

robertmassaioli commented Mar 21, 2015

So this is hitting me too on OSX. This issue has been going on for a while. I'm experiencing it too. I can also confirm that simply trying to open one file with SFML results in a crash every single time I run my program:

* thread #6: tid = 0x0005, 0x000000010497808d OpenAL`OALSource::RemoveBuffersFromQueue(unsigned int, unsigned int*) + 473, stop reason = signal SIGSTOP
  * frame #0: 0x000000010497808d OpenAL`OALSource::RemoveBuffersFromQueue(unsigned int, unsigned int*) + 473
    frame #1: 0x000000010496c77d OpenAL`alSourceUnqueueBuffers + 441
    frame #2: 0x0000000104934cb9 libsfml-audio.2.2.0.dylib`sf::SoundStream::clearQueue() + 109
    frame #3: 0x0000000104934298 libsfml-audio.2.2.0.dylib`sf::SoundStream::streamData() + 1260
    frame #4: 0x000000010495acae libsfml-system.2.2.0.dylib`sf::priv::ThreadImpl::entryPoint(void*) + 26
    frame #5: 0x00007fff8aeea899 libsystem_pthread.dylib`_pthread_body + 138
    frame #6: 0x00007fff8aeea72a libsystem_pthread.dylib`_pthread_start + 137
    frame #7: 0x00007fff8aeeefc9 libsystem_pthread.dylib`thread_start + 13

The original issue (#541) was from March 2 last year, meaning that this issue has been going on now for about one year and one month. Would be great if we could fix this. Would really help with an app that I am writing that I hope to have depend on SFML.

In the meantime I'm going to try my code out on Linux just to make sure that this issue is OSX specific. Also, I'll try and check out this branch and see if it works on OSX.

@robertmassaioli

This comment has been minimized.

Show comment
Hide comment
@robertmassaioli

robertmassaioli Mar 21, 2015

Okay, after installing this branch on my OSX machine and compiling it into my code sf::Music::openFromFile always returns false on my WAV files. I'm not sure if this is a legitimate problem that I was not aware of with SFML 2.2 because of the other OpenAL issues. But I thought that you should be aware of what I was experiencing so that you could test it out too.

I'll try to dig further; if I find anything further I'll drop it here.

robertmassaioli commented Mar 21, 2015

Okay, after installing this branch on my OSX machine and compiling it into my code sf::Music::openFromFile always returns false on my WAV files. I'm not sure if this is a legitimate problem that I was not aware of with SFML 2.2 because of the other OpenAL issues. But I thought that you should be aware of what I was experiencing so that you could test it out too.

I'll try to dig further; if I find anything further I'll drop it here.

@robertmassaioli

This comment has been minimized.

Show comment
Hide comment
@robertmassaioli

robertmassaioli Mar 21, 2015

Oh yeah, to build your code:

cd /path/to/your/branch/checkout
mkdir localbuild && cd localbuild
cmake ..
make
make install

Then I pointed my code to that build of SFML. If I missed a build step then just let me know; that would explain why the audio files are not loading. Cheers.

robertmassaioli commented Mar 21, 2015

Oh yeah, to build your code:

cd /path/to/your/branch/checkout
mkdir localbuild && cd localbuild
cmake ..
make
make install

Then I pointed my code to that build of SFML. If I missed a build step then just let me know; that would explain why the audio files are not loading. Cheers.

@robertmassaioli

This comment has been minimized.

Show comment
Hide comment
@robertmassaioli

robertmassaioli Mar 21, 2015

However examples/sound works on my machine using your checkout. So I must be doing something wrong. :)

robertmassaioli commented Mar 21, 2015

However examples/sound works on my machine using your checkout. So I must be doing something wrong. :)

@robertmassaioli

This comment has been minimized.

Show comment
Hide comment
@robertmassaioli

robertmassaioli Mar 21, 2015

Okay, I am actually generating the WAV files in advance (as part of my build process) that need to be played by SFML later. I am using libsndfile to generate those files and the format that I was using was: SF_FORMAT_WAV | SF_FORMAT_PCM_32. However, it turns out that any WAV files with 32 bits of data will fail to be play correctly. I had to change the format to SF_FORMAT_WAV | SF_FORMAT_PCM_16 and now it works great with this branch!

You can find the WAV file with 32 bits per sample here. I raised a new issue about that here: #834 Sorry for writing all over your issue.

robertmassaioli commented Mar 21, 2015

Okay, I am actually generating the WAV files in advance (as part of my build process) that need to be played by SFML later. I am using libsndfile to generate those files and the format that I was using was: SF_FORMAT_WAV | SF_FORMAT_PCM_32. However, it turns out that any WAV files with 32 bits of data will fail to be play correctly. I had to change the format to SF_FORMAT_WAV | SF_FORMAT_PCM_16 and now it works great with this branch!

You can find the WAV file with 32 bits per sample here. I raised a new issue about that here: #834 Sorry for writing all over your issue.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Mar 21, 2015

Member

This PR has been added to my merge list, meaning it will be merged soon, unless someone raises any concerns.

Member

eXpl0it3r commented Mar 21, 2015

This PR has been added to my merge list, meaning it will be merged soon, unless someone raises any concerns.

@robertmassaioli

This comment has been minimized.

Show comment
Hide comment
@robertmassaioli

robertmassaioli Mar 21, 2015

After more testing this branch makes my code work on OSX. It has a bug thumbs up from me.

robertmassaioli commented Mar 21, 2015

After more testing this branch makes my code work on OSX. It has a bug thumbs up from me.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Mar 25, 2015

Member

Merged in ce16554

Member

eXpl0it3r commented Mar 25, 2015

Merged in ce16554

@eXpl0it3r eXpl0it3r closed this Mar 25, 2015

@robertmassaioli

This comment has been minimized.

Show comment
Hide comment
@robertmassaioli

robertmassaioli Mar 25, 2015

This is excellent, when is the next release planned for? OSX users could really use this fix.

robertmassaioli commented Mar 25, 2015

This is excellent, when is the next release planned for? OSX users could really use this fix.

@zsbzsb

This comment has been minimized.

Show comment
Hide comment
@zsbzsb

zsbzsb Mar 26, 2015

Member

when is the next release planned for?

When the 2.3 milestone is complete.

Member

zsbzsb commented Mar 26, 2015

when is the next release planned for?

When the 2.3 milestone is complete.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Mar 26, 2015

Member

@DomT4, if you plan to update brew formula for SFML 2.3, you might want to be aware of this. ;-)

Member

mantognini commented Mar 26, 2015

@DomT4, if you plan to update brew formula for SFML 2.3, you might want to be aware of this. ;-)

@zackthehuman

This comment has been minimized.

Show comment
Hide comment
@zackthehuman

zackthehuman Sep 1, 2015

Hi. I'm still experiencing the issue described in #541, which I reference in a bug for my project (hakase-labs/hikari#233). I'm building SFML 2.3 from source, but I also tried 2.2 and 2.1. Should it be possible to experience the same threading-related crash even with 2.3?

zackthehuman commented Sep 1, 2015

Hi. I'm still experiencing the issue described in #541, which I reference in a bug for my project (hakase-labs/hikari#233). I'm building SFML 2.3 from source, but I also tried 2.2 and 2.1. Should it be possible to experience the same threading-related crash even with 2.3?

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Sep 2, 2015

Member

Should it be possible to experience the same threading-related crash even with 2.3?

Probably not. Make sure you don't have old binaries/headers still on your system when you clean build your app.

If it's still happen, let me know.

Member

mantognini commented Sep 2, 2015

Should it be possible to experience the same threading-related crash even with 2.3?

Probably not. Make sure you don't have old binaries/headers still on your system when you clean build your app.

If it's still happen, let me know.

@eXpl0it3r eXpl0it3r self-assigned this Sep 9, 2015

@Ceylo Ceylo deleted the Ceylo:bugfix/541_osx_openal_threadsafety branch Dec 29, 2017

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