RFC: Routing and Priority lists

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Hi,
> 
> I've written up my latest proposal to gather feedback before starting
> (hopefully soon now) on the implementation.
> http://www.freedesktop.org/wiki/Software/PulseAudio/RFC/PriorityRouting
> 

Thank you for improving the routing infrastructure, Col! 
I have a few questions & suggestions, based on previous customer requirements for a MeeGo tablet product:

1. Can Pulseaudio register the default playback and some role's priority list automatically, with default weight?
  Even if the application does not register any priority lists, pulseaudio can build the default playback priority list by itself and add persistent and new plugged devices into the list. And if a device has "device.intended_roles" set, Pulseaudio can also build a role-based device list if it does not exists yet and add the device to it. By default, the role-based list has a higher priority than the default list. 
  If the application want to customize routing, it can register new priority lists or update an existing list's weight, as well as updating the entries.
  
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.

3. When a new card is created, can the card tell the properties of all its device+port for all profiles, before the sink/source are created? 
  Profile switch is always our concern. 
  When a card is created, it shall list all profiles and the device+port under those profiles. The properties can include "name", " device.intended_role" and sample spec. So even if a device+port is not created, we can still add them to the priority list and know which profile is necessary to create them. The routing system need check card's availability and switch profile if necessary. For example, when a new BT headset is connected, its HSP sink will be injected to the "phone" and default priority list, and its A2DP sink will be injected to the default priority list too. For a phone stream, the routing system can match HSP sink from "phone" priority list at first, and if the HSP sink is not available but the BT card is available, it will set card profile to HSP and route sound to the new available HSP sink. And when the phone ends, routing system will find A2DP sink is more suitable for active media streams and switch BT card to A2DP profile, considering sample rate and channel numbers. Here the stream priority is also involved, and stream creation/destruction can also trigger profile switch and re-routing, as we discussed before 
http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-September/011398.html

Thanks & Best Regards
Mengdong


	




[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux