SDL Audio

[hnefatl]

Hi all,

In my program, which uses SDL, I have a SFX that runs every 4 seconds (roughly), whenever a ball hits a paddle. However, it is always about 0.5 seconds out of sync. The ball hits the paddle, bounces off it, then the music plays afterwards. It's not a huge gap, but it is easily noticeable and for me quite annoying.

This is the relevant code:

if (/*Checks for collision between ball and paddle*/) {
        //Play the thunk sound:
        Mix_PlayChannel(-1, thunk1, 0);
        //Increments data about how many times the ball has been hit
        bounces++;
        //Creates the "Bounce" effect
        yVel=(0-yVel);
    }

Is there any way to speed up the playing of the sound? I've tried editing the silence from start of the sound using an audio editor, but it has made little difference. I think it's the overhead needed to call the Mix_PlayChannel() function that slows it down.

I've considered checking to see if the ball will hit the paddle if it continues on it's current trajectory, then plays the sound so the sound actually sounds closer to when the ball hits the paddle, but I would prefer not to use this method, as it might not calculate right.

Any suggestions are welcome,
hnefatl

[Peter87]

Have you tried passing a smaller chunk size to Mix_OpenAudio? A larger chunk size gives more sound delay.
http://jcatki.no-ip.org:8080/SDL_mixer/SDL_mixer.html#SEC11

[Disch]

Yeah this is known as audio latency and is unavoidable with how software audio buffering works. The best you can do (with a software mixer) is minimize the latency by using a smaller buffer/chunk size as Peter87 suggested, but of course that increases the risk of buffer underrun.


Try to think of audio streaming like an hourglass. With an hourglass, you put a bunch of sand in the top and it slowly trickles out the bottom at a steady rate. If you start to run out of sand, you can put more and more sand in the top to keep the flow going.

Streaming audio is the same idea. You have a buffer that slowly empties as sound is played. You put more sound in that buffer as it empties to make sure that there is always audio data available to play. The larger the buffer, the less risk of you "running out" of audio data, but the more latency there is (ie: bigger delay between when you put the audio in the buffer and when it's actually played).




On a side note this is one of the reasons why I don't really like SDL. If you let the hardware do the mixing this is a nonissue (and you usually get better performance, besides)... but SDL only really supports a single audio device and therefore forces you to do all mixing in software. Other libs like OpenAL solve this problem another way and can greatly reduce audio latency with very little risk of underrun.

[hnefatl]

Ok, Thanks for your information. Can OpenAL be linked with SDL? I noticed that OpenAL is for 3D applications; can you just utilize the Audio part but not require the 3D window?

Alternatively, is there a work-around for Audio-latency?

Thanks,
hnefatl

[Disch]

Can OpenAL be linked with SDL?

Yes, although I don't recommend working with it directly. It's low level and kind of weird to handle. It's better to use with a wrapper lib (kind of like how SDL wraps around DirectSound or something similar, you can get other libs to wrap around OpenAL)

SFML is one such lib. I actually recommend you consider leaving SDL entirely and switching to SFML. It's basically the same idea as SDL except a bit more modern:

http://www.sfml-dev.org

I noticed that OpenAL is for 3D applications; can you just utilize the Audio part but not require the 3D window?

It has capability for 3D audio. That doesn't mean you have to use those capabilities. If you just want normal stereo it can do that just fine.

The window/graphics that you have makes no difference at all. You don't even need any graphics at all for it to work.

Alternatively, is there a work-around for Audio-latency?

Not if the mixing is being done in software.

[hnefatl]

@Disch Great, thanks for all the information. Greatly appreciated.

hnefatl

[bluecoder]

great .. i like that thanks @Disch