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

[Mikel Astiz]

Hi Tanu,

On Mon, Feb 18, 2013 at 5:59 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> 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.

Thanks again for the review.

>
> 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.

This could make sense to keep backward compatibility, but I think it's overkill.

>
> 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).

I already have some patches that follow David's proposal, which I will
probably submit today.

AFAIK the form factor of a paired device should remain constant so I
can't think of a real-life issue with port names. There's no real
use-case for this.

In the worst case, if a device hypothetically changes the form factor
due to some strange reason, it's not clear whether the old port
settings/policies should apply. So I wouldn't bother much about this.

Cheers,
Mikel