Allegro 5 on Raspberry Pi -- Sound Sample Delay Problem

I'm trying to get back into dabbling with C/C++ programming on the Raspberry Pi using Allegro 5. A while back I ran into a problem with sound sample delay issues, using v5.1.7. A played sample delays maybe a half second to play, which is quite noticeable. I can actually replace the calls to al_play_sample with system calls to aplay for almost no lag, granted the program hiccups badly, I presume in large part from loading the sound file from disk, so clearly not a solution.

I just tried setting up v5.2.0.0 and I see the issue still persists. Just wondering if anyone has encountered this and knows of a fix. Anyone out there using Allegro on the RPi? I saw a video on YouTube of a game that utilized Allegro on the RPi and I saw no sound lag issues so it would seem there is a working config out there for the RPi that works.

I made the A5 bouncer example play a sound when the bouncer hits the borders. See attached video (compressed with XVID) for an example of the delay.

I've been trying to cobble together instructions on setting-up Allegro on the RPi from scratch using the latest version of Raspbian. I can post the instructions if it would be of help once I clean them up.


Chris Katko

You should also attach the source code for your simple example.

myoung said:

I've been trying to cobble together instructions on setting-up Allegro on the RPi from scratch using the latest version of Raspbian. I can post the instructions if it would be of help once I clean them up.

I've got two Pi's. I'd be interested in that tutorial.


Sure, I'll clean-up the instructions and post them. They are based on instructions from other sites, probably postings from other members here. I found the need for more verbose instructions coming from Windows and not being strong with Linux.

My source code is attached. Again, it's simply the A5 bouncer example playing samples. You can see the commented out lines for calling aplay to play the sounds. If you comment out the sample play lines and uncomment the system calls to aplay you can see what I'm talking about -- almost no lag that way, though horrible hiccups in the program, so not a solution -- just a way to see the delay in audio playback problem.

The same program, compiled on x86, be it Windows or Linux (I use Ubuntu), has no sample playback lag.

Here are the steps I've performed to get Allegro 5 working on my RPi from a fresh image of Raspbian...

These steps are taken from what I've cobbled together from replies on this forum, instructions on the Internet, and some trial and error back when I was tinkering with Allegro 5.1.7, then cross-checked with updated instructions found here...


I don't have a RPI - but which audio driver are you using? If not PulseAudio, try using that - worth a try at least.

Mark Oates

Raspberry Pi 1, 2, or 3?


In the setup instructions I'm using...

...I install libpulse-dev before I run cmake. I'm open to any suggestions. I've nuked and paved my Raspbian image many times trying to find a solution.

I'm using a Raspberry Pi 1 Model B, though I was thinking of getting a Rapsberry Pi 3 as having used one they are pretty peppy over my Raspberry Pi 1 Model B. I understand the hardware is somewhat uniform so maybe I'd run into the same issues though.

Open to any suggestions as this is a real buzzkill as I think Allegro is awesome and the Raspberry Pi is an awesome platform! Thanks!

UPDATE: I impulse acquired a Raspberry Pi 2 B from Craigslist to see if a clean setup makes any difference. Probably won't, though if this gets figured out, being able to compile a third faster will be welcome!

Chris Katko

Even the 2 is worlds faster than the 1. I couldn't even run Transmission-GTK with my Pi 1 without the entire GUI freezing when it tried to download a Ubuntu torrent at ~2 MB/s.


Okay, so I think I have the high latency issue resolved. It would seem to be an issue with the Raspberry Pi's sound hardware, or at least that's the perhaps simplistic conclusion I draw from getting low latency audio playback using USB headphones. I have heard the Raspberry Pi's audio is a little flaky and that external USB audio adapters have been handy with the RPi. Here's what I found works...

1) Disable the Raspberry Pi's on-board sound hardware.
2) Connect USB headphones to the RPi.
3) Reboot.
4) Specify to use PulseAudio before I initialize audio in my program.
5) Start PulseAudio.
6) Run my program.

Further details of steps 1, 4, and 5...

1) Disable the Raspberry Pi's on-board sound hardware by opening the terminal, typing in the following command...

sudo nano /etc/modprobe.d/raspi-blacklist.conf

...adding the following line to it...

blacklist snd_bcm2835

...and saving the file.

4) Before calling al_install_audio() have these lines of code...

al_set_config_value(al_get_system_config(), "audio", "driver", "pulseaudio");
al_set_config_value(al_get_system_config(), "pulseaudio", "buffer_size", "512");

5) Start PulseAudio by opening the terminal and running the following command...

pulseaudio --start

I think I'll be getting a few USB external audio adapters to try. If that is the most feasible solution then it's rather unfortunate. Kind of clumsy to have such hardware hanging off the USB ports. Alas, it would seem to be an inexpensive solution.

Also, regarding the intermittent error I was getting on the Raspberry Pi 2 when running the A5 bouncer test program...

XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
      after 9 requests (8 known processed) with 0 events remaining.

...I wasn't getting that issue whatsoever on the RPi 1 B. What's the difference between the RPi 1 B and RPi 2? The CPU. The RPi 2 is quad core. When I edit the /boot/cmdline.txt, adding...

maxcpus=1 the end, saving the file, and rebooting, the program runs reliably. Not sure what's up with that -- if there are any special switches to use when compiling with GCC to prevent that error.

Thread #616314. Printed from