So I've talked about suspend/resume and the challenge for audio
devices. Basically, the problem is that bad things can happen for some
devices when user threads fail to keep the audio system's buffers full
-- underruns can cause popping in some case, and worse problems in
others (for Dolby Digital AC3, underruns or loss of data might be
catastrophic for the audio app.) The problem we have is that there can
be a fairly long time between the window were user-threads are stopped,
then restarted.
For audio, we need to "suspend" the audio system as early as possible
after user threads are suspended (or maybe even before!), and resumed
fairly late -- probably even after user threads are resumed.
So, what I'm thinking of doing is hooking a thread into the callb
framework that picks up on the CB_CL_CPR_POST_USER class, and suspends
the audio subsystem when CB_CODE_CPR_SUSPEND is issued, and resumes it
when CB_CODE_CPR_RESUME is issued. The thought here is that this may
(hopefully) eliminate underruns that occur during CPR resume.
I'd like folks from the PM team to sanity check this approach. Is this
the right approach? Or should I do something like the SRN notification
used by X? (That would mean inventing something new.) Or invent new
specific CPR classes for audio?
Let me know what you think.
Thanks!
- Garrett
