On Mon, 3 Nov 2008, Garrett D'Amore wrote:
> 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
>
One question here, is if there are user threads that need a
notification or syncronization? If so, a POST_USER callback will be
too late. If, on the other hand, it is only kernel objects, then a
CPR callback makes sense, and quite possibly the POST_USER point
works. Whether a new class(s) is needed, will depend on if what is
there is sufficient.
If userland suspend notification/syncronization is required, then it
seems as if SRN is your only option.
Possible issues that might also need to be resolved, is how should
the hardware devices should handle suspend after the audio framework
is suspended, as well as resume before the framework.
Cheers!
---- Randy
