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
