[pulseaudio-discuss] [RFC v1 0/6] Add card profile availability

[Tanu Kaskinen]

On Mon, 2013-02-18 at 09:10 +0100, Mikel Astiz wrote:
> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
> 
> Second proposal integrating Tanu's comments:
> 1. pa_availability_t used for both port and profile availability.
> 2. Carefully consider profile "off" in automatic profiles witch policies.
> 3. Availability of "bluetooth-input" and "bluetooth-output" handled separately.
> 
> From original cover-letter:
> 
> It has been recently discussed how ports should be used in the
> Bluetooth card module, whether they should be merged or not, and how
> the bluetooth-related information is exposed to both external
> components (i.e. UI) and internal policy modules.
> 
> In a nutshell, the problem is as follows: the internal policies are
> interested in profile-specific information (HSP/HFP vs A2DP) while the
> ports should ideally be associated to physical entities (and the
> Bluetooth profile should make no difference).
> 
> A natural way to solve this problem is by adding a new flag to the
> card profiles, representing the availability of each profile. This is
> similar to port-availability but with different semantics,
> representing the state of each invidivual Bluetooth profile.
> 
> This patchset extends the core with such a flag, which sounds useful
> even beyond the scope of this specific problem (a UI could use this
> information to gray out profiles).
> 
> Mikel Astiz (6):
>   core: Rename pa_available_t to pa_available_t
>   card: Add card profile availability
>   cli: Show card profile availability status
>   bluetooth: Expose card profile availability
>   bluetooth: Use profile availability to auto-switch profiles
>   bluetooth: Merge all ports into "bluetooth-input" and
>     "bluetooth-output"
> 
>  src/modules/alsa/alsa-mixer.c                   |  12 +-
>  src/modules/alsa/alsa-mixer.h                   |   2 +-
>  src/modules/alsa/alsa-ucm.c                     |   4 +-
>  src/modules/alsa/module-alsa-card.c             |  10 +-
>  src/modules/bluetooth/module-bluetooth-device.c | 324 +++++++-----------------
>  src/modules/bluetooth/module-bluetooth-policy.c | 105 ++++----
>  src/modules/module-switch-on-port-available.c   |  20 +-
>  src/pulse/def.h                                 |  18 +-
>  src/pulse/introspect.c                          |  10 +-
>  src/pulse/introspect.h                          |   6 +-
>  src/pulsecore/card.c                            |  20 ++
>  src/pulsecore/card.h                            |   4 +
>  src/pulsecore/cli-text.c                        |  13 +-
>  src/pulsecore/core.h                            |   1 +
>  src/pulsecore/device-port.c                     |  10 +-
>  src/pulsecore/device-port.h                     |   4 +-
>  src/utils/pactl.c                               |   4 +-
>  17 files changed, 228 insertions(+), 339 deletions(-)

Thank you! I've applied all.

The port renaming causes some problems if the old names are saved
anywhere. PulseAudio saves the port names in the card-restore database
(it's used for saving the port latency offset). We don't know how many
users use the old port names for something (e.g. in scripts).

I wonder if we should have an alias database, which would be populated
with old port names whenever a port is created.

Another question is that should the port names reflect the device form
factor? IIRC, David has previously argued that they should. I'm not so
sure. If we don't have the port alias database, there would some
breakage whenever we learn a new form factor (not a common occurrence,
but still).

-- 
Tanu