[OSX 10.9] Audio somehow freezes program a few seconds on exit


I have the same problem as explained here: https://www.allegro.cc/forums/thread/613698

I've tried to replicate the problem in the smallest amount of code possible, but haven't succeeded yet. But in the codebase I have now, if I remove al_reserve_samples(), the program quits immediately - if I add it back the program waits for 10 seconds (after the window is gone) before it really quits.

I'm not sure how to debug this. Has anyone looked into this yet?


I managed to replicate the problem in the smallest amount of code:

1#include <allegro5/allegro.h> 2#include <allegro5/allegro_audio.h> 3#include <allegro5/allegro_acodec.h> 4#include <memory> 5 6int main(int argc, char *argv[]) 7{ 8 al_init(); 9 10 std::shared_ptr<ALLEGRO_EVENT_QUEUE> queue = std::shared_ptr<ALLEGRO_EVENT_QUEUE>(al_create_event_queue(), al_destroy_event_queue); 11 std::shared_ptr<ALLEGRO_DISPLAY> display = std::shared_ptr<ALLEGRO_DISPLAY>(al_create_display(640, 480), al_destroy_display); 12 13 al_install_audio(); 14 al_init_acodec_addon(); 15 al_reserve_samples(16); 16 17 al_register_event_source(queue.get(), al_get_display_event_source(al_get_current_display())); 18 19 bool quit = false; 20 while (!quit) { 21 ALLEGRO_EVENT event; 22 al_wait_for_event(queue.get(), &event); 23 24 switch (event.type) { 25 case ALLEGRO_EVENT_DISPLAY_CLOSE: 26 quit = true; 27 break; 28 } 29 } 30 31 return 0; 32}

Arthur Kalliokoski

Are there corresponding al_destroy_sample()'s at exit? Just guessing here.

Edgar Reynaldo

To debug you can add in some al_get_time() statements and see how long it is between measurements around each line of code. Something else you can do is run it through the debugger and when you think it is busy doing its thing, then hit CTRL-C and break execution. Then

info threads

and usually check out thread 1, but sometimes all you get is weird system calls. Do a


on each thread by switching threads with

thread N

. You don't always get anything useful unless all your libs are debug. Call al_uninstall_audio and the other shutdown functions manually and see which ones take the longest. That may help narrow it down.


When I run this:

1// g++ -Wall main.cpp -o main -lallegro_monolith 2#include <allegro5/allegro.h> 3#include <allegro5/allegro_audio.h> 4#include <allegro5/allegro_acodec.h> 5#include <iostream> 6 7int main(int argc, char *argv[]) 8{ 9 al_install_system(ALLEGRO_VERSION_INT, 0); 10 11 ALLEGRO_EVENT_QUEUE *q = al_create_event_queue(); 12 ALLEGRO_DISPLAY *d = al_create_display(640, 480); 13 14 al_install_audio(); 15 al_init_acodec_addon(); 16 al_reserve_samples(16); 17 18 al_register_event_source(q, al_get_display_event_source(al_get_current_display())); 19 20 while (true) { 21 ALLEGRO_EVENT e; 22 al_wait_for_event(q, &e); 23 24 if (e.type == ALLEGRO_EVENT_DISPLAY_CLOSE) 25 break; 26 } 27 28 std::cout << "destroy display" << std::endl; 29 al_destroy_display(d); 30 31 std::cout << "destroy queue" << std::endl; 32 al_destroy_event_queue(q); 33 34 std::cout << "uninstall audio" << std::endl; 35 al_uninstall_audio(); 36 37 std::cout << "uninstall allegro" << std::endl; 38 al_uninstall_system(); 39 return 0; 40}

It gets stuck at al_uninstall_audio(). I'll try to investigate further.

What is weird is this though: if I comment out the while loop, the program runs and quits immediately. ???

Peter Hull

I traced this all through and the 'slow' part seems to be a call to AudioQueueDispose in aqueue.m.

1/* The stop_voice method should stop playback. For non-streaming voices, it 2 should leave the data loaded, and reset the voice position to 0. */ 3static int _aqueue_stop_voice(ALLEGRO_VOICE* voice) 4{ 5 ALLEGRO_AQ_DATA *ex_data = voice->extra; 6 7 if (playing == true) { 8 playing = false; 9 10 ex_data->playing = false; 11 12 AudioQueueDispose( 13 queue, 14 true 15 ); 16 } 17 18 return 0; 19}

The second parameter to AQD can be false to dispose of the queue asynchronously and I wonder if that mode might help. Of course, it may well be set to true for a good reason.



Seems Elias fixed it? https://github.com/liballeg/allegro5/commit/d6d58b28b018e065770bb96b7276fe2cc002cad6

I recompiled allegro with the fix and now my example above quits immediately as it should.

Peter Hull

I don't know if that makes me feel really clever or really dumb. Anyway, glad it's fixed.
Maybe the powers that be should consider backporting the fix for 5.0.10?

Thomas Fjellstrom

Maybe the powers that be should consider backporting the fix for 5.0.10?

We need to sit down and make someone do some backporting. And then make a release.

Thread #614696. Printed from Allegro.cc