Okay, so I'm having a little difficulty.
The problem is that although audio gets suspended "early" (along with
other devices), during the few seconds of resume, the system is so busy
that I can't get enough CPU cycles to keep the audio buffers "full".
Furthermore, if I resume the audio playback, I run into a problem where
audio applications haven't been resumed yet, and I'm back in the
situation of having an underrun.
I can imagine on record I could have the inverse problem, where
applications failing to run (and drain the record buffer) result in
record overruns.
So what I'd *like* to do is find some way to defer the resume somewhat
-- ideally the device would be "resumed" once user threads have started
back up and the system is once again more or less stable.
Anyone have any ideas on how to defer the resume action? (I was
possibly thinking about a sysevent handler or a daemon thread that could
receive SIGTHAW, but I'm not sure this ideal either.) Is there some way
to handle this elegantly with the CALLB framework? (I'm in ON, so I can
use consolidation private APIs.)
-- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
