When upgrading 2.3.2 to 2.4.2 Loading sounds is fairly longer.

[MJBrune]

I load all of my small sound effects on start and it's only 11 files totaling about 40 mb. Before in 2.3.2 the load time for this was smaller than a second. Currently it can take up to 30 seconds. A far longer delay in sound loading.

I basically do this:

void AudioManager::loadSound(std::string directoryPath, std::string soundFile)
{
   if (!soundBufferManager[soundFile])
   {
      soundBufferManager[soundFile] = new sf::SoundBuffer();
      soundBufferManager[soundFile]->loadFromFile(directoryPath + soundFile);
   }
}

Where audiomanager has this in it's constructor:

   std::vector<std::string> soundFiles = AWT::getWavFiles(AWT::getAssetFolder() + "sounds/effects");

   for (auto filename : soundFiles)
   {
      loadSound(AWT::getAssetFolder() + "sounds/effects/", filename);
   }

So basically I just load them all up and play them whenever and the sit in memory cause they are small.

The sounds themselves haven't changed and if I go back to 2.3.2 the sounds load much faster.

Any ideas? Should I just attempt to disperse the loading? even then each sound file can take up to 2-3 seconds.

[Laurent]

Have you tried SFML 2.5.0?

[MJBrune]

Yeah, same results with 2.5.0. I first noticed this on 2.5.0 Also this seems to only happen on windows as well.

[eXpl0it3r]

Can you profile it and see where the time is wasted? What about the release build, is it also slow in release? What format are you audio files in?

[MJBrune]

They are all wav files.

Does SFML have any profiling tools for this? I'm only calling sf::SoundBuffer::LoadFromFile() on several (11) wav files. How would you recommend digging into this? I could watch my disks but they are all SSD and am not noticing the same thing with textures and etc.

It still happens on release builds as well as debug.

I'm focusing on 2.5.0 as it seems best to do that but wanted to ensure I got the introduction version correctly for this behavior.

[eXpl0it3r]

A profiler is either part of your toolchain or can be installed as additional tool. It will show you where most of the time is spent in your code as well as any code it has debug symbols for. So you could see what's going inside of SFML.

Do you run an AV software? Try to disable it once, to see if it may have an impact.

[MJBrune]

Yeah I know what a profiler is but I load symbols and get this: https://imgur.com/a/aV64OyG

Stops at loadfromfile soundbuffer class in sf. Also check out the memory usage. It's fairly low.

[eXpl0it3r]

I think in SFML 2.3 we switched the audio implementation, which meant we run our own WAV reader.
Starting up the profiler on my side, the culprit seems to be the following line

while ((count < maxCount) && (static_cast<Uint64>(m_stream->tell()) < m_dataEnd))

More specifically the call to tell() which in turn calls std::ftell(), which seems to be rather slow.
For reading 10 relatively short WAV files, I see 8278 calls to tell() using up 84% of the time.

I wonder if it wouldn't be enough to just have the count and drop the tell() call entirely.

Edit: Removing the second check made everything load in the ms range again and so far nothing crashed. Looking at the OGG reader it seems we don't have that stream check there either and just do count < maxCount.

Laurent: Do you think it's safe to remove?

Created a PR, so feel free to comment there as well.

[MJBrune]

https://github.com/SFML/SFML/commit/698bbccd6a0e2bb3971b052996a78b39272c8b3c looks like it introduced it although didn't seem to attempt to fix anything? Was this a feature added?

[eXpl0it3r]

Ah right, could have checked when it was introduced. I remember this fix, the problem was that WAV files can have metadata at the end of the file, as such you can't just read till EOF, but you need to stop at the audio stream ending. Maybe we can manually track the position, instead of relying on tell().

[MJBrune]

Yeah I also noticed you call Tell twice in one loop. The top of the while loop and at 290/289. Maybe just caching the tell result might be enough to cut this issue in half?

Edit: Uhh NVM github was showing me that page weirdly. Ignore that. XD

[RealmRPGer]

Just chiming in on this. I think a new solution will need to be found. This is incredibly slow and it's unrealistic for real-world games to suffer a minute+ delay just from loading sounds.

At a bare minimum, a non-compile bypass will need to be added (eg, an ignoreMetaData argument in SoundBuffer::loadFromFile)

edit: I took a quick look at the code. I'm not 100% how the read() function works, but couldn't the decode function return the number of bytes read, and the current position be tracked that way, instead of using tell()?

[eXpl0it3r]

This was already fixed: https://github.com/SFML/SFML/pull/1450

The root cause is basically an issue with Visual Studio/Windows code (see this Twitter conversation) where ftell takes longer than fread and feof combined., which reminds me, that I still haven't written a bug report for that...

[RealmRPGer]

Thank you. I pulled the latest build and is indeed a lot faster. Though it is still fairly slow (takes ~10 seconds to load all the sounds vs less than 1 second in 2.3.2). Are there any plans to take another look at this?

[eXpl0it3r]

Can you use a profiler and provide the callstack that takes the longest?