On Fri, 06.02.09 16:04, pl bossart (bossart.nospam at gmail.com) wrote: > Hi Lennart, > I like the idea of modules being able to send events to a client. That would > work for clients who connect directly to pulseaudio, with some additional > modifications internally. For example the pulsesink would sent a message on > gst_bus to request the app to pause. At FOSDEM I talked t the gst folks about that, and yes, the plan is to map this to a message on gstbus. > However in the case where apps use ALSA and see the PCM routed to PulseAudio > by the ALSA-lib pulse plugin, that wouldn't help at all, would it? The > cork request would need to be sent to the original application, using DBUS > or something. Yes, of course. Folks using an abstraction layer that abstracts features away won't be able to make use of this directly. That is not particularly surprising, isn't it? Marc-Andre pointed me to MPRIS, and suggested implementing pause/resume based on that: http://mpris.org/ The MPRIS API is very much flawed in my eyes (i.e. racy: the definition of the Pause() call is just stupid, makes it impossible to use this for software that gets the events in question by some other way as well). Also, I am always a bit unsure about having PA connect to the session bus since the sesson bus runs on the machine that runs the rest of the session while PA is usually run alongside X on the client side and hence relying on this kind of communication will break network transparency/thin client stuff. In addition to that none of the relevant media players really supports MPRIS. (Where's Rhythmbox? Where is Totem? Where is Banshee?) I am a bit unsure how to map the conbnection to the right service. i.e. is prefixing the executable name with org.mpris good enough? But OTOH, having said all this it should be easy to implement a module that forwards the pause events to MPRIS as well, by adding a tiny hook that allows intercepting of the request-pause/request-resume events. There's also another optiont: we could use XTEST to synthesize XF86XK_AudioPause and XF86XK_AudioPlay key events on X. That way gnome-settings-daemon will pick them up and dispatch them to the media player apps. This would be pretty simple and thin-client-safe. OTOH it doesn't allow targeting the events to specific applications. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4
