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.
> 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.
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.
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)
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.
Maarten
