jackskelyton at March 5th, 2008 20:45 — #1
I've been working with the OpenAl streaming tutorial from this site and I've got it working fairly well. However, I find I'm getting a similar problem to the one described here: http://www.devmaster.net/forums/showpost.php?p=6225&postcount=46
When my program switches to full-screen mode, the ogg files stop playing. I upped the buffer size to 4096*32, still stopped when going to fullscreen. Switched from using 2 buffers to 4, and it works great. I can switch screen modes, minimize, do anything I want and the ogg still plays. However, at the end, it coctinually streams the last buffer. Using 2 buffers does not have this problem, but as mentioned before, just won't work for my needs. Any ideas as to why the last buuffer repeats?
I'm getting the exact same problem. I haven't tried using four buffers, but I notice that no one in that thread addressed the root of his problem, which was "Why does the stream hiccup if your try to resize the window?" Anyone have a idea?
martinsm at March 6th, 2008 16:16 — #2
It's because when you start resizing window your main thread which pumps messages (at least on Windows) enters modal loop. It means that code execution stops during DefWindowProc call. That's why OpenAL consumes all available queued buffers and stops playing anything.
To solve this you have two options:
* when you are updating and queueing buffers, you also check if music is playing - if not, then resume playback (just issue play command). Of course user will notice silence when window is resizing, but he will get back his music.
* a little bit harder solution is to move your music update loop to another thread. This involves some basic synchronization between threads when communicating about which music must be started or stopped. But at least your music update loop will be executing even when user is resizing window.
jackskelyton at March 6th, 2008 18:51 — #3
Thank you, that makes sense. I tried replicating the example above, using four buffers, and found that it works without incident---no doubt because the queue has enough content with four buffers in the queue to "wait out" the modal loop. Somewhere down the line we also intend to thread our sound code, so I will post here with the results of that.