Problem with sf::Music on loop with the latest SFML Version

[Ironbell]

Hey all,

We've updated our game on Github to use SFML as a submodule. The version of SFML that we were using before was SFML 2.2 and everything worked fine with the music loop in our level. With the new SFML version however, the music loop didn't run smoothly and when I looked into the logs, the following message appeared after every loop:

(click to show/hide)

An internal OpenAL call failed in SoundStream.cpp(435).
Expression:
   alBufferData(buffer, m_format, data.samples, size, m_sampleRate)
Error description:
   AL_INVALID_VALUE
   A numeric argument is out of range.

The code we are using to instantiate the music looks like this:

(click to show/hide)

// the music path references a .wav file
if (m_backgroundMusic.openFromFile(m_currentLevel.getMusicPath()))
{
                m_backgroundMusic.setLoop(true);
                m_backgroundMusic.setVolume(g_resourceManager->getConfiguration().volume);
                m_backgroundMusic.play();
}

Has anyone an idea why the AL check might fail? Any help is greatly appreciated.

[eXpl0it3r]

Which version is "the new SFML version"? master branch or 2.3.2?
What compiler do you use?
And what's the OS you're testing this on?


Also hello fellow Swiss citizen!
Your project looks quite interesting.

[Ironbell]

Our project references the master branch.
The problem occurred on Windows 8 x64 (Visual Studio 2013 x64 in debug mode) and also in Mac OS X 10.11 (compiler: clang) and was never seen before the update.

Also, it's nice to see that there are Swiss people working on SFML

[eXpl0it3r]

What audio format are you playing? Can you provide that file?


I'm not the only Swiss on the SFML team.

[Ironbell]

We're only playing .wav files. The particular file lies @ https://github.com/tizian/Cendric2/raw/master/res/level/ratcave/cave_try.wav. Please don't judge, it's only a placeholder track to test the music in the game.

[Hapax]

I tested it using your sound file and it failed to loop correctly for me too.

"Failed to loop correctly" also means - for me - that it seems to stutter at the end (repeats a small part) before starting from the beginning again.

I tested debug, release, debug (static), and release (static).

Windows 7, SFML release version 2.3.2 (32-bit)

UPDATE: I opened your file in Audacity and resaved it as a .WAV file and it no longer has OpenAL errors. It does, however, click, but that's just imperfect looping. I also resaved it as an .OGG file and it works perfectly.
Here they are:
cave_try 2.wav
cave_try 2.ogg

[Ironbell]

I've tried the two files you provided and they work for me just like they do for you. It still seems pretty strange to me - I'm going to save them from now on in the .ogg format. But anyway, thank you very much for the kind responses and your efforts! 

[eXpl0it3r]

I've tried the same thing (with Audacity) and have gotten the same result. While trying to figure out why, I could only find that when the loop starts filling the buffer, the size varies between the two files. The original file contains 13824 samples, while the modified file contains 13839 samples.
From SFML 2.2 to 2.3 we switched from libsndfile to vorbis, ogg and flac. The question probably is why libsndfile accepts it without problems.

For music OGG is anyways recommended, since it's compressed.

[FRex]

Also, it's nice to see that there are Swiss people working on SFML

The conspiracy runs much deeper than that.
Here's the list of Simple Swiss and Fast Multimedia Library devs from GitHub to which I added their nationalities:

Laurent Gomila - French
Marco Antognini - Swiss
Jonathan De Wachter - Belgian (speaks French)
Jan Haller - Swiss
Stefan Schindler - German
Lukas Dürrenberger - Swiss
binary1248 - Swiss
Artur Moreira - Portuguese
Mario Liebisch - German??

As you can see, 8 out of 9 people in it speak one of Switzerland's official languages* and half of that group is Swiss.

Yes, yes, yes, I know there are dialects and varieties and so on but still!! Swiss conspiracy!!

[zsbzsb]

I tested it using your sound file and it failed to loop correctly for me too.

"Failed to loop correctly" also means - for me - that it seems to stutter at the end (repeats a small part) before starting from the beginning again.

Hapax, when you say 'stutter' do you mean it sounds like the audio file from this post?

[eXpl0it3r]

I can hear a "stutter" as well. It sounds more like a short interrupt. Since one function call on a buffer fails it just might fill it wrongly.

[Ironbell]

Also, it's nice to see that there are Swiss people working on SFML

The conspiracy runs much deeper than that.
Here's the list of Simple Swiss and Fast Multimedia Library devs from GitHub to which I added their nationalities:

Laurent Gomila - French
Marco Antognini - Swiss
Jonathan De Wachter - Belgian (speaks French)
Jan Haller - Swiss
Stefan Schindler - German
Lukas Dürrenberger - Swiss
binary1248 - Swiss
Artur Moreira - Portuguese
Mario Liebisch - German??

As you can see, 8 out of 9 people in it speak one of Switzerland's official languages* and half of that group is Swiss.

Yes, yes, yes, I know there are dialects and varieties and so on but still!! Swiss conspiracy!!

Swiss Fast Multimedia Library made my day. That makes working with it even more fun and it really fits for our project, as the game will be available in English, German aaaand yes, Swiss German. 

I can hear a "stutter" as well. It sounds more like a short interrupt. Since one function call on a buffer fails it just might fill it wrongly.

Do you think it's an OpenAL bug or that the .wav file is really corrupted? The latter would bug me; it's created with Fruity Loops and I'm planning to use that program also for other sound in the game.

[eXpl0it3r]

I'm not exactly sure. Fact is libsndfile can open it fine (otherwise Audacity would have an issue), so it might well be SFML's implementation. The issue itself seems to be that SFML passes a wrong size to the OpenAL function, which would end up in an overflow.

The only thing I've noticed when quickly debugging it, is that data.samples is slightly different between the original one and the one from Audacity: 27648 vs 27678

Maybe Laurent, who wrote the WAV thingy implementation, would be faster at figuring it out. But if I got some more time next week, I'll try to look at it more closely.

[Laurent]

I'll try to have a look.

[FRex]

I dug into it a bit.
I've got a Python script online ( http://blog.theroyweb.com/extracting-wav-file-header-information-using-a-python-script ) and checked out the wav file:

python wav.py cave_try.wav
Subchunks Found:
fmt ,  data,  smpl,  acid,  LIST, 

Data Chunk located at offset [36] of data length [9376744] bytes
ByteRate:  176400
BitsPerSample:  16
NumChannels:  2
Subchunk1Size:  16
ChunkSize:  9376914
Format:  WAVE
AudioFormat:  1
BlockAlign:  4
SampleRate:  44100
Filename:  cave_try.wav

The data length is 9376744 bytes.
But I checked and SFML wav file reader reads 9376878 bytes from the wav in total.
I also checked and ogg file has exactly 13772 samples in last array it passes to OpenAL, while wav has 13839.
This checks out: SFML reads 9376878 - 9376744 = 134 extra bytes and since samples are 16 bit it's exactly 13839 - 13772 = 67 samples, 2 bytes per sample, 134 bytes.
If I hardcode it to change size of last array to 13772 when count is 13839 (cutting off the extra 67 samples) then it works perfectly for wav too.
So SFML assumes that last chunk is data till end of file and reads it blindly, which results in reading some chunks that are other stuff as samples, which produces the extra samples that cause stutter and OpenAL error.
I have no idea why it casues OpenAL error though.
This error has nothing to do with looping, BTW. If you play the wav just once it'll stutter at the end and cause the OpenAL error too.

And this is what last 134 bytes are in hex and ascii:

[frex@localhost audiobug]$ tail --bytes=134 cave_try.wav | xxd -g 1
00000000: 73 6d 70 6c 3c 00 00 00 00 00 00 00 00 00 00 00  smpl<...........
00000010: 94 58 00 00 3c 00 00 00 00 00 00 00 00 00 00 00  .X..<...........
00000020: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 02 00  ................
00000030: 00 04 00 00 00 00 00 00 f9 c4 23 00 00 00 00 00  ..........#.....
00000040: 00 00 00 00 61 63 69 64 18 00 00 00 00 00 00 00  ....acid........
00000050: 3c 00 80 00 00 00 00 00 50 00 00 00 04 00 04 00  <.......P.......
00000060: 9a 99 b4 42 4c 49 53 54 1a 00 00 00 49 4e 46 4f  ...BLIST....INFO
00000070: 49 53 46 54 0d 00 00 00 46 4c 20 53 74 75 64 69  ISFT....FL Studi
00000080: 6f 20 31 31 00 00                                o 11..

Looks too good as ascii (FL Studio 11 ) to be samples so it's probably metadata and the like.

Edit: Oh, also - Sound does not have this problem, because SoundBuffer uses InputSoundFile::getSampleCount which returns correct value. Music has the problem because it keeps calling the reader, which in case of wav reader goes YOLO till end of file, reading in some additional data that it shouldn't. That's why the bug sat there undetected for so long, wav for sounds works fine, and for music most people use ogg because of file size.

The only thing I've noticed when quickly debugging it, is that data.samples is slightly different between the original one and the one from Audacity: 27648 vs 27678

data.samples as in the value of samples itself? Or did you mean count (that number is way too little to be sample count for such a long file BTW)? Anyway - Hapax's file does not cause OpenAL error but it also has extra non data bytes at the end (112 of them) that SFML treats as samples. And Hapax's and original ogg are same, exactly same, byte for byte. And all four files (wav and ogg, both Hapax's and OP's) correctly return 4688372 as sample count from InputSoundFile::getSampleCount.