Use of locks in sf::SoundStream::onGetData

[Misopeth]

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.

[Foaly]

Like you said it is generally a very bad idea to allocate memory or do any kind of blocking operation in a "realtime" situation. onGetData would be one of them. Where exactly in the tutorial do you see memory being allocated or locks being used?

[Laurent]

sf::SoundStream is triple-buffered, so you won't block playback if you spend a little more time in onGetData.

[Misopeth]

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.

[Laurent]

There's nothing wrong with locks, really. Don't overthink this stuff.

[Misopeth]

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).

[mynameisjohnj]

Hi All,

I hate to resurrect this thread, but I have kind of a relevant question and feel like there are enough soundstream questions high up at the moment (though I'll make a thread if noone responds).

It's good to know that the sf::SoundStream's onGetData function is passing you the third of three buffers used for streaming, as I wasn't really sure if this was the case. Could this be added to the docs?

Also, would you say the onGetData function is a reasonable place to do some mixing / processing? Nothing too ridiculous, but... well let's just put some numbers to it.

If I push say 2 seconds worth of audio in each onGetData call, that means that while 2 seconds play there are two seconds ready to go and 2 seconds I'll be asked for. Does that mean I've got the time it takes to play those two seconds to process and push new audio?

Sorry if that's difficult to read... let me know if I can be more clear / if I should make a new thread. And by the way, thanks to all the developers for working on SFML. It's people like you and libraries like this that make life worth living.

[Laurent]

Could this be added to the docs?

I don't like to bother people with too many implementation details, but yes, I see that this one may have an impact on user code so it may be worth mentioning it.

would you say the onGetData function is a reasonable place to do some mixing / processing?

Sure it is.

Does that mean I've got the time it takes to play those two seconds to process and push new audio?

Indeed.

[mynameisjohnj]

Merci!