[pulseaudio-discuss] Sink for event sounds? WAS: paplay - sound roles?

[Lennart Poettering]

On Tue, 05.01.10 15:12, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> 
> 'Twas brillig, and Colin Guthrie at 05/01/10 15:03 did gyre and gimble:
> > 'Twas brillig, and Lennart Poettering at 05/01/10 14:54 did gyre and gimble:
> >>> Yup and the general decision that this approach is "a good thing" and
> >>> something that should be exposed to users. I know Lennart doesn't like
> >>> the idea of this being something users have direct control over, but
> >>> it's something I hear people asking for over and over. Perhaps it's just
> >>> because the automatic approaches don't work, full and there are other
> >>> ways but I quite like the transparency and relative simplicity (i.e.
> >>> users can easily grasp how it works as opposed to black magic hidden
> >>> foo) this approach offers.
> >>
> >> Nah, the automatic scheme I have in mind has not been tested
> >> yet. Right now we store no history of previous settings that could be
> >> used when the newest setting cannot be applied because a device is not
> >> plugged in or suchlike. So what I have in mind is simply have a stack
> >> of choices. Whenever a user makes a choice the stack entry for it is
> >> put on top. If it existed before it is thus removed from the stack
> >> first and moved to the top. If it didnt exist it is created newly.
> >>
> >> That way the user can easily configure the order of devices simply by
> >> moving streams if the order is wrong and that's it. No complex UIs for
> >> that.
> > 
> > Ahh right yes. Too many discussions fly about for this tiny brain!
> > 
> > Hopefully the actual database in the m-d-m is sufficient for this and
> > all that's really needed is an additional module to manupulate it
> > automatically..... For role based sink moves this wouldn't even conflict
> > with the KDE approach - it's just a simple GUI like pavucontrol (which
> > doesn't support role based sink moves yet) would have the effect of
> > promoting the destination to the top of the list...
> > 
> > Cool.
> 
> (erm, obviously the m-d-m database stores only role-based priorites... I
> guess it could be expanded to store application based priorites too -
> like m-s-r.

If you make sure that m-d-m installs its hooks so that they are
executed after m-s-r's hook you could simply rely on the
module-stream-restore.id property to be set in which we store the
actual db key we use. if you rely on that you can be sure that you use
the same id mechanism as m-s-r.

Lennart

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