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

[Lennart Poettering]

On Wed, 11.02.09 16:55, Marc-André Lureau (marcandre.lureau 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.
> >
> 
> Hmm, that's how GSmartMix was doing it, but it's probably not enough.
> We need to discuss that thoroughly with interested parties during
> developer meeting. I can't wait!!

Not enough? We discussed this pretty thoroughly at our GStreamer
meeting at FOSDEM which lasted a couple of hours. And the conclusion
was that two new GstBus messages might be sufficient. Why do you think
it wouldn't be?

Dude, you should have come to the Gst meeting!

I'll sit down and write a summary of that meeting, stay tuned.

Uh, and regarding the developer meeting: in contrast to what I
expected after getting good feedback at foss.in and FOSDEM about
organizing this meeting I only heard back from very few people until
now. Colin and Liam responed, Including you and me that would make
just 4 people. Intel folks, where are you?
 
> >> 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?
> >
> 
> Please Lennart, don't ignore 96% of applications (yes, very accurate,
> eh!) by implying it's there fault. At least, let's try to convince
> them, not ignore them.

I am not saying that it is anyone's fault. I just state facts. 

I think the *right* way to forward the request-pause/resume events is
inline in the audio device. Now, for native PA clients this is trivial
to do and for Gst we mostly agreed on a scheme. For other interfaces
things are more problematic. We can add kludges (like MPRIS support) to
make apps using those work, but that doesn't change the fact that the
*right* way is to get those notifications inline instead of passing
them out-of-band. And generally I prefer to implement the correct way
first and than add the compatibilty kludges on top of that if
necessary.
 
> > Marc-Andre pointed me to MPRIS, and suggested implementing
> > pause/resume based on that:
> >
> > http://mpris.org/
> >
> 
> yes, because they started long ago, altough without the "policy" case
> or "distributed" case in mind. In many ways, I dislike this API, I
> even started a pet project called MEPRIS (to have disdain in french),
> which is now called EPRIS (sort of "in love"),
> http://code.google.com/p/epris/ (check "Why?" section)

Sounds interesting. It would be good if there was a spec like MEPRIS
that didn't suck as much.

I'll post something on their mailing list that explains my issues with
that spec. Maybe they'll listen.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4