Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » [OSX 10.9] Audio somehow freezes program a few seconds on exit

This thread is locked; no one can reply to it. rss feed Print
[OSX 10.9] Audio somehow freezes program a few seconds on exit
Arvidsson
Member #4,603
May 2004

Hi!

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?

edit:

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

#SelectExpand
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
Second in Command
February 2005
avatar

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

“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

Edgar Reynaldo
Member #8,592
May 2007
avatar

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

backtrace

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.

Arvidsson
Member #4,603
May 2004

When I run this:

#SelectExpand
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
Member #1,136
March 2001

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

#SelectExpand
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.

Pete

Arvidsson
Member #4,603
May 2004

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
Member #1,136
March 2001

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
Member #476
June 2000
avatar

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Go to: