Fade-in volume problem

[eigen]

Hi.

First off, I'm using a version built from git repository a few months ago (I checked the log and the audio files haven't been updated in 6 month so it doesn't matter anyway).

Let me try to explain my issue:

When-ever I play a sound, like a button click or random sfx, it starts out quiet and then fades in. The fade is rather quick (~60-90 ms maybe) but if it's a really short sound (like a button bleep or bloop), then it never reaches the set volume and is basically un-hearable. It happens with longer sounds as well. Also, it happens with musics. I can distincly hear the music starting out quietly.

If I manage to play a sound twice in a row (like double clicking or whatever), then the second time it's played at the right volume but if the previous instance has completed playing when playing again, it's back to un-hearable.

It happens both on Windows (Win 7) and Mac ( 10.8 ). But there's a slight difference: on Windows it works fine when I plug in my earphones. When played trough the speakers, the issue arises. BUT, when I start the game with headphones plugged in and then un-plug them, the speakers work fine. Windows might use different output devices/drivers for each case (I'm not sure) which SFML then picks up on start-up? I have updated my drivers. It's a brand new machine anway, but still. I also have an old XP machine and that works fine. Again, it might be something with the audio drivers/devices.

On Mac it doesn't matter, it's always bugged. I think it was fine on the previous OS version but I'm not sure. It was defintely fine with SFML 1.6.

That's all I can think of right now. It was also broken in the RC version.

Okay, one more thing. On Mac, I tried playing the sounds with the Finder play button thingy on the file icon. It doesn't work. If the sound is longer, it does. VLC also doesn't play anything. But Audacity does. It's almost like if the sound data isn't long enough, it bugs out.


Here are a couple of sound files:

Very short bleep - It's finished before reaching its set volume in SFML

Longer bloop - does reach the volume, but the fade is noticable


One more thing I tried: I added 5 seconds of silence to the end of the first file and then during those 5 seconds, whenever I replayed the sound, it was fine. As soon as the first play ended, the issues was back. It's like it drops the buffer then and has to re-initialize everything on next play.

[eigen]

Nevermind! I did some reading up on OpenAl, and since it's for 3d sounds mainly, it got me thinking that maybe it doesn't like mono.

It doesn't, as it turned out! The sounds have to be stereo. Single channel doesn't cut it. It seems to be working on Mac at least, I'll try it on Windows once I get home.

I don't know what I was hearing with the music then, since that's already stereo. Maybe just some loading thing since music is streamed or whatever.



edit: Converting sounds to stereo seems to have only fixed the issue on Mac. On Windows I still have the problem as described.

[tylerstreeter]

I'm having the same problem: when I first play a sound, the first ~50ms fades in, but if I replay it before it has finished, there is no fade-in. If I wait for the sound to finish and replay it, the fade-in is present again. This is especially noticeable for sounds with a lot happening in the first 50ms... otherwise, I would not have noticed this problem.

I'm using SFML 2.0 on OS X.

I did some reading up on OpenAl, and since it's for 3d sounds mainly, it got me thinking that maybe it doesn't like mono. It doesn't, as it turned out! The sounds have to be stereo. Single channel doesn't cut it.

Hmm... that seems backwards to me. See the SFML sound spatialization tutorial: http://www.sfml-dev.org/tutorials/2.0/audio-spatialization.php. It says:

A sound can be spatialized only if it has a single channel, i.e. if it's a mono sound. Spatialization is disabled for sounds with more channels, since they already explicitely decide how to use the speakers. This is very important to keep in mind.

In any case, it appears that spatialization could be part of the sound fade-in problem, as eigen described. I too tried converting my sound files from mono to stereo, and that does seem to fix the problem (no more fade-in). I'm assuming this simply disables spatialized sound, just as the tutorial said.

I also tried disabling spatialized sound programmatically (still using mono sound files) by calling sound.setRelativeToListener(true), and leaving the default sound position at (0,0,0), which is described later in the same tutorial:

This can be useful for sounds emitted by the listener itself (like a gun shot, or foot steps). It also has the interesting side-effect of disabling spatialization if you set the position of the audio source to (0, 0, 0).

I was hoping that this alternate method of disabling sound spatialization would also remove the fade-in problem without having to modify my sound files. Unfortunately, it doesn't seem to fix the problem.

If anyone has any more info on this sound fade-in problem (like another way to disable sound spatialization programmatically), it would be appreciated.

[tylerstreeter]

UPDATE: I created a simple OpenAL example on OS X 10.8.2 (no SFML at all), and this fade-in problem is still present (again with mono sound files but not stereo files). So the problem is in OpenAL.

Even if I force the sound source to be at the listener's position, like this:

alSourcei(sourceID, AL_SOURCE_RELATIVE, AL_TRUE);
alSource3f(sourceID, AL_POSITION, 0.0f, 0.0f, 0.0f);
alSource3f(sourceID, AL_VELOCITY, 0.0f, 0.0f, 0.0f);

...the problem remains.

Does anyone know how to avoid this problem in OpenAL?

[Laurent]

If your OpenAL implementation is OpenAL-soft, then you should ask its author directly.

[tylerstreeter]

If your OpenAL implementation is OpenAL-soft, then you should ask its author directly.

I'm using the default OpenAL implementation on Mac (in /System/Library/Frameworks/OpenAL.framework).

For now I'll just use stereo files to work around this problem. Even though this isn't an SFML bug, I thought I would mention what I found here for future reference...