TODO: describe problems with not-freeing resources in user sessions
Since the only device currently being used by Speech Dispatcher is the audio device, the direct access to the device could be moved onto an intermediary who will take care of claiming/freeing the hardware resource as necessary. Currently, such technology is available (Pulse Audio) and a driver for it already exists in Speech Dispatcher. The problem arises with other audio backends present in Speech Dispatcher, most notably ALSA. Because of the audio system on the Free Desktop platform not being standardized and because of cross-platform requirements, we can't entirely get rid of such low level drivers.
ConsoleKit provides a very easy way to determine if the current session is active, as well as events for activity state changes.
Two solutions are to be considered:
- Handling session activity change in server core
- Handling session activity change in audio subsystems
Solution (1) supposes that the server listens to ConsoleKit activity state change events and in case the session becomes inactive, broadcasts this event to all it's modules. The modules will then free hardware resources (audio). This solution has the advantage that in case synthesis requests for immediate playback are received during session inactivity, it will be able to refuse them and not waste CPU by synthesizing messages that will never be heard. The responsibility not to waste CPU can however as well be attributed to Speech Dispatcher clients.
Solution (2) is localized into the audio subsystems. The audio subsystem will keep the audio device free during session inactivity. Only those audio subsystems need to do this which directly claim the hardware. For example in the Pulse Audio module this functionality is not needed as it is provided by Pulse Audio itself.
- ConsoleKit IDLE session – not related directly. Without the IDLE session, Pulse Audio is currently not useful in situations where there is no real active sesion (as dorring bootup, in login screen etc.)
- Pulse must not be dependent on X in standard configurations – not directly related (same as (1))