SFML community forums
Help => Audio => Topic started by: ptrxyz on June 25, 2009, 01:34:05 am
-
I use SFML 1.5 (latest SVN) with .NET. I experienced a small delay after calling SOUND.Play().
Ok, lets check this:
Dim boomBuf As New SoundBuffer("hq_boom.wav")
Dim somesound As New Sound(boomBuf))
With New Microsoft.VisualBasic.Devices.Audio
somesound.Play()
.Play(ByteArrayThatConatainsTheAudioFile, AudioPlayMode.Background)
End With
What it does is basically load a sound into a buffer and create a sound object.
Then it instanciates a new .NET-Audio Device and then starts playing with both objects (the default .NET player and the SFML Sound).
The sound file I load is just a WAV with a single short "beep".
If both sounds would start playing right after another (like it should be) one would more or less just hear a "bebeep". But what you hear is "beep"...(delay ~300 to 500msec)..."beep".
The SFML sound is delayed. I realized this when I was making a simple application (Press key -> play sound). One could really "hear" the delay, it is pretty much too long for...let's say a game with a rocket exploding or something.
So, anyone got an idea about this? I saw someone posted something similar a few weeks ago but that problem got fixed back then, so this can / should not be related to this.
I just tried if it got fixed in SFML2-branch...but no, same think. Playing starts slightly delayed. =(
Edit: The order I start the sounds playing doesnt matter (first .NET-Player then SFML-Sound = same like first SFML then .NET). There is always a delay.
-
Is the sound already loaded when you play it? If not, the delay may just be the time needed to load it from the file :)
-
I dont really know how SFML loads the sounds, but if it loads the sounds when I create a Soundbuffer-instance then it was loaded. And I ran the test in a loop so after the first run it should be loaded, right?
-
Yep, after this line the sound is loaded
Dim boomBuf As New SoundBuffer("hq_boom.wav")
Can you provide a short and complete test that reproduces the problem? So that I can quickly test it myself.
-
Ok, I uploaded a little quick'n'dirty demo program: http://www.itak.de/share/audioplay.rar
So what I do there is:
- Load the sound in a SFML SoundBuffer and create a sound object
- Load the sound in a byte array and create a .NET Audio Device
- Start two threads, one for SFML one for .NET Audio Device
- Wait for the threads to synchronize
- Start both players
- Should result in a single "beep", but I hear a "bebeep" (--> one is delayed)
But uhm, now that I benchmarked it that way I just found out that the delay more or less is just a few msec (< ~30msec). So it should not matter and SFML should be working correct. I must have messed up something with the original code were I thought it would be delayed much more...
I guess you can close the topic Laurent. Seems it was a false report. Sorry for that.
-
The delay might be caused by the fact that you're running two totally different sounds at the same time from the same application; the driver / hardware / whatever may not support it well.
Anyway, if you want a good test, you can setup your SFML sound so that it loops, and let it play. If you can notice a gap between two consecutive play, then there's a problem ;)
-
Those delays are usually due to a lack of frequency of audio buffer pumping, maybe the audio thread has a lower than useful priority.
When the CPU is on heavy load it could happen, it happened to me a lot in MAME with some heavy games in an old computer.
Instead of *Kyaaaaaaaaaaa* it would sound like
Ky-ky-ky-ky-y-y-ya-ya-ya-ya-ya-a-a-a-a-a-a :lol:
What happens if you drop the thread sync?
-MartÃn
-
If i drop it one thread starts like 50msec earlier...so there is a something like a "BeeBeep" instead of a "Beep" so to say.
But it's ok, I guess it wasnt a SFML problem. I realized that the sound was delayed in a total different application I made. I double checked my code and couldnt find a problem with it, so I thought it was SFML's fault. I made the benchmark and it seems everything is fine. I think a third check on my code will reveal the bug. =)