В Пнд, 30/10/2006 в 09:15 +0000, Richard Hughes пишет: > I've been asked to play a sound when the battery is critically low [1] > and also when suspend fails and the lid is closed [2]. The latter is > very important, as some laptops (including macbooks) can actually *melt* > if the lid is closed and they are still running. (!) > > So, what is the best way to do this? I really don't want to build in the > whole of the gstreamer stack[3] just to play "alert.wav" at volume "90" > once in the lifetime of the session. > > Also, using something like > > gst-launch filesrc location=error.wav ! wavparse ! osssink > > Will probably break on some systems (OSS vs ALSA) and seems very hacky > to me. I'm guessing we're not counting on ESD being around anymore, > although I could be wrong. >
Gstreamer has higher level API for playing files. You probably want to use something like playbin element. This way you'll reuse GNOME multimedia settings for default sink element and eliminate ALSA/OSS/ESD problem. Also you'll detect media file format automatically. I don't think it's a problem to link to gstreamer and play sound file this way for application that wants to play sound. > Some users (imagine working in a library) won't want *any* noise in any > circumstance and some users will want the volume all the way up. > > At the moment I'm erring on an out-of-process gnome-power-sound > executable that we just send it an argument to play a sound, so as to > keep gstreamer out of process. But this seems very much a hack. > libgnome has two interfaces for playing sound. First of all, it's simple interface for playing sound file from gnome-sound.h. This interface should be reimplemented with gstreamer api mentioned above or application can use gstreamer api directly. Second interface is for events. That's more advanced thing that you are looking for. It's described in gnome-triggers.h file. Some apps like gnome-games use this interface for playing sound events. And you should use this interface as well in gnome-power-manager. This way you'll respect user settings for sound events done in control-center. Of course libgnome api uses esd and a is bit obsolete. To replace it I suggest to reimplement this functionality in notification-daemon. It's the application that should cache events and play them on demand. So my opinion is that you should extend notification-daemon dbus api to play events instead of creation of strange gnome-power-sound. Using dbus api libgnome-triggers might play events in notification-daemon. It should not be hard to do all work and I am even willing to code something but the only things that stops me is an agreement on such extension of notification-daemon. > I'm guessing this is very much a gnome-wide problem, hence the mail to > d-d-l. > > Better ideas (or screaming insanities) welcome. > > Thanks. > > Richard Hughes. > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=365700 > [2] http://bugzilla.gnome.org/show_bug.cgi?id=346542 > [3] > http://svn.sourceforge.net/viewvc/gaim/trunk/gtk/gtksound.c?revision=17204&view=markup#l_389 > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
