[pulseaudio-discuss] Musings on stream device and volume restore rules

Tue Mar 24 16:59:45 PDT 2009

In the case of USB headsets I think a rule that says if a new local output
appears "move all streams (new and current)" to it option would cover 90% of
cases with an option to toggle the rule off?

Thats what I have running anyway at it works as I'd expect

Jason Taylor

2009/3/25 Colin Guthrie <gmane at colin.guthr.ie>

> Disclaimer... I'm a bit tired and haven't proofed this as much as I'd like.
> And I wrote most of it while in an airport and quite bored.
>
> The suggestions are my own thoughts and opinions but are perhaps based on
> inaccurate assumptions, so feel free to correct me and change my opinion!
>
>
>
>
>
> Stream Memory Database and Restoration Rules
> ============================================
>
> This document outlines the needs and use case for the stream memory
> capabilities in pulseaudio and how this information should be used. It
> finishes with recommendations for implementation.
>
> Restrictions
> ============
>
> The system employed needs to be simple and allow for fully server based
> management and application of the rules. The logic should be kept simple
> with minimal overhead but still be powerful enough to meet all the needs of
> current actual and potential use cases.
>
>
> Current System
> ==============
>
> Currently module-stream-restore stores various metadata on streams it sees.
> This currently consists of:
>  * volume
>  * channel map
>  * mute status
>  * device (optional)
>
> It stores this metadata under a key that governs how it is matched again in
> the future.
>
> The key itself has two parts, a prefix from a predefined list and a suffix
> relating to the specific stream in some way.
>
> Prefixes include:
>  * sink-input-by-media-role
>  * sink-input-by-application-id
>  * sink-input-by-application-name
>  * sink-input-by-media-name
>
> (where "sink-input" could also be "source-output" for input streams)
>
>
> The specific identifier is suffixed on the end of this, to create a final
> key that is stored and queried in the database to give final keys of e.g.:
>  * sink-input-by-media-role:event
>  * sink-input-by application-name:MPlayer
>  * etc.
>
> When a stream is started, module-stream-restore will pick exactly one key
> that it will use to identify a stream. If the stream has a media role
> property it will use *-by-media-role. It then falls back to check the
> different identifiers, in order, as outlined above.
>
>
>
> Problems
> ========
>
> The current system has a couple limitations.
>  1. If a stream has a media role, it is impossible to save a volume for the
> specific application with that role as the key sink-input-by-media-role:xxxx
> will always take precidence over a sink-input-by-application-name:yyyy keyed
> rule.
>  2. If an application is modified to start providing new metadata (e.g. a
> role) the entries for that specific application that were used
> (sink-input-by-application-name) will no longer be matched and the data will
> be stale in the file. This is not really a major problem.
>  3. The current system only allows for one device to be matched, not an
> ordered priority list.
>
>
> NB 3 is only strictly problemati in the case of Phonon integration which
> uses such a scheme.
>
>
>
> Use Case
> ========
>
> To think about what we need to change in the system we need to look at what
> the user wants out of the system.
>
> For the most part we want routing rules to be automatic, but still allow
> the user the degree of control they need.
>
> For comparison, Phonon has a device priority list system that allows each
> role to prioritise the output devices they want to use. When a stream with
> that role is played, it will go through the list of devices until it finds
> one that is currently avaialble (i.e. it keeps track of devices that are no
> longer present - e.g. USB sound cards) and uses that. It offers this
> priority list for each role, as well as a "global" list, which is used when
> no role is provided by the application. Generally speaking, users seem happy
> with this arrangement and this degree of flexibility (albeit there are not
> many Phonon applications to expliot this flexibility fully yet.
>
> Looking at native pulse applications, the "default" sink option in
> pavucontrol (or more correctly in the daemon itself) is the most commonly
> misunderstood option and amounts to by far and away the most common support
> issue: "I've changed my default to my USB but application X still plays
> sound via my Interal card". From an internal prespective, we do not consider
> this to be a "default" sink at all, but rather a fallback and arguably
> calling it "default" was a mistake, but the fact remains that users want an
> "active" default capability in the system somewhere, where changing the
> default device will actually move any active streams across to that device
> if they are currently using a different default. Probably the second most
> common support question is: "I set my USB to default, but then unplugged it
> and the application started playing on my internal speakers... Great! But
> when I plugged my USB back in it didn't move it back. What's up?".
>
>
> What to do
> ==========
>
> With the above use cases in mind, it's clear that the current system needs
> to be revised to cope. In summary the problems we want to address are:
>  1. Allow for an "active" default
>  2. Allow for a prioritised list of devices to be created (on a per-role
> basis - finer grained control would be too much).
>  3. Allow for applications which have the same role to have independant
> volumes saved.
>
> To this end, I think the current volume/map/mute/device database is
> incorrect. With the flat volume support, I think per-application volumes are
> more appropriate, rather than per-role.
>
> I think that a key->device->priority table is needed to allow for a given
> role identifier to have it's own rules written appropriately. Pulse needs to
> remember the sinks (and sources) both past and present (including their
> "nice" name (description)) and provide a way for a UI app to purge a
> currently unavailable sink (e.g. remove it from the cache).
>
> When a stream is encountered, it's role should be checked and the
> prioritised list of devices loaded for that role. As in Phonon, if a stream
> does not have a role a "default" priority list should be used. (Optional) A
> subsequent check should be made to see if any specific rules state that this
> individual application has a preferred device to allow for fine grained
> control. If such a rule exists the device should be move to the top of the
> already loaded priority list or injected there if it does not exist
> (unlikely). The stream is then restored to the first available device. This
> priority list should be saved with the stream so it can be easily
> re-evaluated at any point should new sinks become available later.
>
> If any priority list is changed (e.g. by a client application) all streams
> should have their cached priority list invalidated and rebuilt (perhaps the
> rebuilding can be lazy - e.g. it's only loaded when needed?)
>
> With regards to volumes etc., these should be saved against a given
> application and not a role. To do so at the role level is unlikely to be a
> useful end user feature.
>
> With this system in place, a neat and effective UI can be produced and a
> good mapping into KDE can also exist which will be good for cross desktop
> accpetance of PulseAudio in the linux world.
>
>
> Implementation
> ==============
>
> Currently the routing decision is only processed by module-stream-restore,
> but this is not sufficient. We need other modules to be able to participate
> in this process. In order to acheive the above, a new hook (or similar)
> should be created to allow separate modules to have a say in building the
> priority list. PA_CORE_HOOK_SINK_INPUT_ROUTE should be called when a new
> stream is created and whenever the routing logic needs to be be recalculated
> (e.g. the rules themselves change (or a module participating in rule
> calculation is [un]loaded), *not* when a new device comes or goes) I would
> suggest that only the device priority list should be handled in this hook.
> The volume restoration should probably be handled within the existing
> PA_CORE_HOOK_SINK_INPUT_NEW hook.
>
>
> --
>
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
>
> Day Job:
>  Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
>  Mandriva Linux Contributor [http://www.mandriva.com/]
>  PulseAudio Hacker [http://www.pulseaudio.org/]
>  Trac Hacker [http://trac.edgewall.org/]
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>

-- 
"A little rudeness and disrespect can elevate a meaningless interaction to a
battle of wills and add drama to an otherwise dull day." - Calven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20090325/68095b7c/attachment.htm>