[pulseaudio-discuss] RFC: Routing and Priority lists

[Colin Guthrie]

'Twas brillig, and Lin, Mengdong at 15/11/11 03:04 did gyre and gimble:
>> So out of the box, a default priority list will start to be built
>> up. For some special cases (as now, such as module-intended-roles)
>> some devices will be injected into certain lists at specific
>> levels. So headset devices (bluetooth or USB) will be used by
>> default for VOIP calls, but probably not for music playback.
> 
> Nice. And It would be helpful if the phone role priority list can
> also be built up out of box, when new headset devices are connected
> :-)

Yeah this is exactly the scenario I'm describing :)

>> One thing I did outline tho', is that when new devices are plugged
>> in (and inserted into priority lists at the appropriate locations -
>> top for headsets in the phone role priority list, bottom  for
>> headsets in other lists etc), the adjusted list will not be written
>> to disk.
> 
> Although I support that the hot-plug triggered list adjustment will
> not be written to disk, " bottom for headsets in other lists etc" is
> not suitable for me because of the customer requests below. I need a
> chance to change the default position, probably through a module as
> you suggested.

Yeah sorry, I'm just describing some examples of how the "where to
inject the device" rules would work. I certainly envisage the ability to
tweak the rules, either via some generic configuration files or via code
in custom modules as you see fit for your use cases.

>>> 2. When a used removable devices is plugged in, can its entry be 
>>> moved to the top of the priority lists that contain the device?
>>> Our customer requests sound always be played through the latest
>>> connected device, no matter this device is new or used before.
>>> And although there is no routing by using the public API calls,
>>> the hot-plug event can be taken as a "user event" to show the
>>> user intention. For example, when a BT headset is connected, its
>>> HSP sink shall be injected or moved to the top of both default
>>> playback and "phone" priority lists. A user can press "handfree"
>>> during a call to route sound to loud speaker/mic from BT, but if
>>> he later connects the BT headset again, he can hear the voice
>>> from the BT headset. We hope this feature can be supported at
>>> least with some kind of configuration, considering different user
>>> requirements.
>> 
>> This doesn't seem like it would be too hard to support. I'll have
>> to have a wee think, but I think this can be supported cleanly
>> enough. It certainly wouldn't be a mode we'd want to configure on
>> the desktop, but I certainly think it can be supported via a
>> relatively simple module you'd load on your config.
>> 
> Would you kindly elaborate on how such a module works? Is there a
> hook for priority list entry update? So this module can change the
> headset entry's position in the list before next round routing is
> triggered.

Not as such, I would envisage some code that looks for new devices
(using the existing hooks) and simply moves them to the top of the
priority lists. There would likely need to be some concept of "startup"
to prevent the built in devices jumping about in the priority lists too
much, but I don't think that will be a major issue.

This code would be pretty simple IMO, and it could be completely stand
along and thus not interfere with other stuff we do (tho' I'm not ruling
out a generic configuration option yet either - it really depends on how
the code looks when I start implementing). But I've not fully processed
your use case yet to comment in any great depth although I don't think
it would be a problem.

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/