'Twas brillig, and Maarten Bosmans at 12/08/11 15:14 did gyre and gimble:
> 2011/8/12 Johannes H. Jensen <joh at pseudoberries.com>:
>> On Thu, Aug 11, 2011 at 10:45, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>>> So I'd say it should simply be supported nicely in gstreamer and then
>>> most applications should behave correctly. As GStreamer is used pretty
>>> extensively on both GNOME and KDE, this covers the majority of cases
>>> right away.
>>>
>>> Add in support for the browsers and we've got quite complete coverage.
>>
>> Right, I see that this feature requires some more work than I first
>> anticipated :)
>>
>>> To Johannes, please do not jump right in and implement a module. There
>>> needs to be more discussion first as I think these kind of policy
>>> modules need to be planned a bit better than the ad-hoc collection we
>>> have right now.
>>
>> Noted. So there's the problem of pausing the streams. Until we get
>> corking support in applications, I think a viable solution is to
>> simply mute them. Do you agree?
>
> Corking a stream is actually just muting it on the pulse side and
> sending a cork message to the app. What the app does with that is not
> so important from the policy module's view.
Yup. In many cases the preferred behaviour would be for the app to pause
themselves, but this may not always make sense (e.g. pausing a live
stream could be something that is not supported).
>> Other than that, I guess we should work out the policy for muting
>> streams. That is, which types of streams are applicable, at what
>> events should they be muted, etc.
>
> I think Colin wanted to discuss what kind of policies should be
> supported and then make a generic module-cork-policy that can be
> configured to work either like module-cork-music-on-phone or earcandy.
Exactly :)
> That would probably be better as a separate module as the generic
> routing-policy Colin has been suggesting for a long time. So you would
> end up with two policy modules: one for corking streams and one for
> moving streams to the desired sink.
I suspect there will also be a couple more - e.g. one (which is perhaps
a modification of or extension to the routing policy) to automatically
switch profiles and one to automatically switch ports - although this
one would likely be done based on external input - e.g. jack detection
and may not be so much a policy module as just pretty much built in
(David already has this kinda working too - it may not fit in exactly
how we'll want it long term but it's pretty nice to see it actually
doing stuff :D)
> So I'd image two different possible lines in default.pa:
> load-module module-cork-policy cork=all cork_on=new-stream
> load-module module-cork-policy cork={role={music,video}} cork_on={role=phone}
> (this is not really a syntax proposal, just an example to get an idea
> of the direction)
Yup, this is exactly the kind of thing I had in mind.
> But perhaps instead of thinking about modules and parameters, it's
> better to think about use case scenario's. So let me kick this of by:
> * Jane is listening to her favorite music. But when a voip call comes
> in, she wants the music to be gone when she answers the call.
> * Johannes does not like several applications playing audio at the
> same time. He only wants to hear sound from the app he is working on.
Longer term, I'd also want to have some other actions - aside from
corking - like reducing the volume of the other streams while a new
stream exists. One example of this being a use case is to simply reduce
the volume of music apps when phone calls comes in (Windows offers this
option) or to lower the volume of music when a the "new message" event
sound is played... this latter one is much more contextual tho' so could
be a bit tricky. I think it's desirable tho' as several phones do this
kind of thing and it's quite nice IMO.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
