[pulseaudio-discuss] why command_cork_playback_stream() will be invoked many times?

[Lennart Poettering]

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