GNOME Bugzilla – Bug 346665
API: sound server interface
Last modified: 2006-07-24 11:11:17 UTC
It would be nice to have an interface for elements interoperating with sound servers. Two methods seem particularly useful (for autoaudiosink for example, see bug #343051): - sound_server_is_running() to check whether a server is running currently - sound_server_is_requested() to check whether the user explicitely requested to use a sound server (e.g. by setting environment variables) It seems cleaner to me to do this with an interface (compared to using object properties). Proposed patch attached. Not sure if it should be GstSoundServer or GstSoundServerControl or GstSoundServerInfo or whatever, GstSoundServer seems most flexible though (and is the shortest). There might be a better name for the is_requested() method as well, but I can't think of one right now.
Created attachment 68411 [details] [review] proposed addition of a GstSoundServer interface
Created attachment 68767 [details] [review] updated patch Same as previous patch, but: - renamed is_requested() => is_requested_by_user() - added use case for is_requested_by_user() to docs
So, any comments? Is it okay to commit this? Or should this be solved differently?
As discussed on irc, I think this is pretty broken, if we don't start sound servers ourselves. Further, I think ever, under any circumstances, starting a sound server ourselves, is even more broken. Given that latter assumption: 1) is_running is roughly equivalent to "can I open this hardware audio device?" 2) is_requested_by_user is never useful. Starting the sound daemon is something that should be done either system-wide (init scripts, or whatever), or session-wide (by gnome-session, etc.). Despite the brokenness of esd, which likes to start itself, this is NOT sensible behaviour.
The entire point of this API was to prevent accidentally starting a sound server during auto-probing. The assumption I was operating under was that it is impossible for us to prevent libesound from starting a daemon in all cases. It seems this is not true and we can probably prevent that from happening using the ESD_NO_SPAWN environment variable. Hence, this API doesn't seem needed any longer, at least not for now. (and FWIW _is_requested_by_user() was useful in the context of the assumptions I was operating under ;))