views:

336

answers:

1

Hello, first time poster here.

I'm writing a multi-threaded streaming audio application in C++ (MSVC) on Windows XP SP2.

The problem I've encountered is that, upon minimizing / restoring any application on the task bar, all threads in my application are suspended while the window animation is active. This affects me because it causes the audio in my application to stutter everytime a window is minimized or restored.

Unchecking the check box titled "Animate windows when minimizing an maximizing" in the windows / system properties / advanced / performance "visual effects, processor scheduling, ..." / Settings / Custom tab seems to resolve this issue.

Adjusting the priority of my process to "High" and "Realtime" do not help.

Can anyone help shed some light on this topic?

+2  A: 

These animations, or painting the window while dragging it around (which should create similar problems) floods the windows message cue with WM_PAINT messages, and cause every little widget/control in your window to redraw itself. This can completely bog down a computer and all the threads and processes running on it.

Two possible solutions:

  • freeze your window, that is throw away any WM_PAINT messages while the window is resizing/minimizing/being dragged. You can also do this by using some kind of flag (lockRedraw) or similar.

    • changing the priority will not help you, it might even increase the problem although I don't know anything about the scheduling strategy of wxp.

Edit: forgot the actual second solution:

  • use bigger buffers for your audio. If you can pass a buffer of maybe half or a full second to the sound card in one swoop, you should absolutely be on the safe side in a multithreaded environment

REEDIT: well I overlooked that you sayd any window. Only solution 2, using bigger buffers, might help there. Sound buffers usually get thrown into some buffer on the hardware, and as soon as they are there, it should be no problem.

Another possibility comes to mind: These animations are underlaid with sounds. Check what kind of sound you have set up for maximizing/minimizing. Switch that off and try again

If the problem persists, it might be due to a poor graphics card driver. If it doesn't, see if your sound (maybe directSound? don't know) settings are all in order. Maybe there's some resource conflict that you can code around. (Not in the hardware manager, but in your way of accessing the sound device.)

AndreasT
ok. The last edit comes as a comment:I just remembered, that the sounds are played regardless of the animtion, and you said it worked then. Do the animations spike your cpu?
AndreasT
The second solution seems to be more likely. (Spy++ showed about 3-6 paint messages per min/restore)Yes, I am using dsound/software buffers. Bigger audio buffers do help, but the overall issue is the other threads delivering the audio to dsound are getting suspended - Transferring real-time voice.
Nope. CPU is idle during windower animations.
Also, windower minimize/maximize/restore up/restore down sounds are "none".
Damn. :| I guess it doesn't happen with let's say skype, or TeamSpeak, does it?
AndreasT
I tested with TeamSpeak and they don't seem to have the problem. It basically comes down to me having to handle a random 200ms sleep anywhere in the audio flow - Not helpful for real-time streaming.I'm trying to figure out why the app is getting suspended rather than refining audio code that works
I do appreciate the advice you've given thus far :-)