Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » [Allegro 5.1.8] Latency when starting a sound effect

This thread is locked; no one can reply to it. rss feed Print
[Allegro 5.1.8] Latency when starting a sound effect
aureus
Member #15,288
August 2013
avatar

I'm running into an issue on a game I'm working on: there is about a 186ms delay between when I call al_play_sample(...) and when the sound effect actually starts playing. This is causing a serious desynchronization of the audio and video. I can adjust for this delay in the case of effects I know will occur ahead of time, but that won't work for sound effects caused by the player's input.

Has anyone run into a problem like this before? How did you solve it?

NOTES:
- I am using the default voice and attaching the samples / streams to the default mixer before playback.
- I preload and pre-attach the sound effects to ensure that there isn't any delay reading from the hard disk.
- The problem isn't the sound effects themselves; I've looked over the waveform to make sure that there isn't any silence at the start.
- I've tried using streams instead of samples for the sound effects, but the latency is still the same.
- The delay seems to be 8192/44100 seconds.

Arthur Kalliokoski
Second in Command
February 2005
avatar

Everybody says to use the stream functions to do this sort of thing.

As far as I can tell, the way the stream functions work is to use al_create_audio_stream(), passing parameters to set the latency to minimum by having two fragments, with a small size for these fragments (to minimize the time needed to play one, reducing latency).

Then as far as I can tell, you load the audio data with al_load_sample(). However, this data isn't any format I can recognize, with a preponderance of zeros, making no sense for floats or ints.

Supposedly, as a ALLEGRO_EVENT_AUDIO_STREAM_FRAGMENT event occurs (using al_get_audio_stream_fragment() to verify), you'd copy the audio data from the first sample that's supposed to be currently playing (to erase data from the last time it was played), then add the data from any concurrently playing samples to mix them. You'd have to check for clipping as you go, I suppose, and SSE functions would work admirably for this purpose, as well as speeding it up.

Take all this with a very large grain of salt, as
"The way to get a correct answer on the internet is to post the wrong answer"

Hopefully somebody more knowledgeable will post the correct info.

[EDIT]

Apparently I need to use al_get_sample_data()

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

SiegeLord
Member #7,827
October 2006
avatar

There's no streaming involved here, Arthur :P.

What OS is this aureus? You could try changing the audio backend used by the audio addon by using allegro5.cfg. Copy that file into the same directory your executable is in, and alter the [audio] driver field.

I have experienced delays recently on Linux when asking for the ALSA backend when it was emulated by PulseAudio. In that case, however, I specifically asked for ALSA using allegro5.cfg, for testing purposes.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

aureus
Member #15,288
August 2013
avatar

The operating system is OS 10.9. Audio driver is set to default, which on this system appears to be AQueue. Looking over the source for aqueue, the buffer size is 1024*2 samples and the buffer count is 4, which explains the 8192/44100 second latency if I understand correctly.

I'll try reducing the buffer size and count and see whether that makes a difference.

EDIT: looks like that was what I needed. Reducing it to three 256 sample buffers allowed me to greatly reduce the latency without causing buffer underflow.

Go to: