Messages

1

Audio / Re: Use of locks in sf::SoundStream::onGetData

« on: February 02, 2016, 09:06:37 pm »

Ok, I'm glad to ear that as avoiding locks really complicates things.

Thank you for your replies (and for the library too, of course).

2

Audio / Re: Use of locks in sf::SoundStream::onGetData

« on: February 02, 2016, 04:28:48 pm »

In the tutorial code there are neither of the two "dangers"; however a race condition might happen as m_currentSample is assigned in onGetData and also in onSeek.
The "Threading issues" section however gives mutexes as an example of protection strategy against concurrent access.
Also, the VOIP example both allocates and uses locks (https://github.com/SFML/SFML/blob/master/examples/voip/Server.cpp#L134).

Speed is not what I'm concerned about; I'm thinking about what could go wrong in acquiring a lock on a mutex, as priority inversion and so on.
I also looked at the code in sf::SoundStream; seems like locks are used in the audio thread.

I'm just pointing out some concerns I have since I am really new to audio programming; I read about using lock-free code in audio programming but I don't know if a careful design could allow the use of locks, as SFML do.

3

Audio / Use of locks in sf::SoundStream::onGetData

« on: February 02, 2016, 03:27:29 pm »

Is it safe to use Locks and/or to allocate memory in sf::SoundStream::onGetData when sub-classing sf::SoundStream?
I mean, in audio callbacks this is usually not allowed as it could cause glitches in the playback, but in the related tutorial (http://www.sfml-dev.org/tutorials/2.3/audio-streams.php) locks are used, so I'm wondering if SFML is already taking care of this.

4

General / Re: Exiting the main method "freeze" the Android application

« on: September 15, 2015, 11:58:27 pm »

I'm pretty new to C/C++ programming, so I don't really know how to track down the problem.

5

General / Re: Exiting the main method "freeze" the Android application

« on: September 15, 2015, 10:52:52 pm »

It works, but only because when the NativeActivity stops the entire application is closed, so there's nothing that could go wrong.

6

General / Exiting the main method "freeze" the Android application

« on: September 15, 2015, 10:22:03 pm »

I'm trying to use SFML to implement a NativeActivity in a larger project.
First a non-native activity is started, after a while this activity start the SFML NativeActivity and when the user press the "back" button (that trigger a sf::Event::KeyPressed with event.key.code == sf::Keyboard::Escape, as sf::Event::Closed doesn't seem to ever be triggered) the NativeActivity closes and the non-native activity should take back the control, but instead it is "freezed" (non-responding).

I copied Android.mk, Application.mk, main.cpp and the needed part of AndroidManifest.xml from the android example.
I'm using SFML 2.3.2.

Am I missing something in the app or window lifecycle?