[pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs

[Georg Chini]

On 25.01.19 10:49, Tanu Kaskinen wrote:
> On Sat, 2019-01-19 at 18:11 +0100, Pali Rohár wrote:
>> This is 5th version of my patch series for modular A2DP codec API and
>> aptX support. The only change for v5 is support for switching codecs.
>>
>> This patch series provides new modular API for Bluetooth A2DP codecs,
>> clean up module-bluez5-device and bluez5-util to be codec independent
>> and convert SBC codec into this new API for A2DP codecs. Also it adds
>> support for aptX, aptX HD and FastStream A2DP codecs.
>>
>> New codec API is designed in way, that for adding new codec is not
>> needed to touch bluez5-util nor module-bluez5-device files. Whole
>> codec registration is done in a2dp-codec-util.c file, without need
>> to update any header file.
>>
>> Some A2DP codecs are bidirectional and support backchannel for
>> microphone voice. This new A2DP codec API fully supports this feature
>> and module-bluez5-device was extended to support microphone voice source
>> for codecs which declares such support. FastStream is such codec.
>>
>> For every A2DP codec is created card profile. When using bluez patches
>> from https://marc.info/?l=linux-bluetooth&m=154696260401673&w=2 then
>> only those profiles codec profiles are created which are supported
>> by remote headset/endpoint.
> As discussed before, I don't think the codec configuration should be
> exposed via card profiles. There is need for being able to say "switch
> to A2DP" without specifying the codec.
>
> It's unclear how priority of the codecs (and their parameter
> permutations) should be configured, but it seems quite clear that a
> "set codec" operation on a specific card would be useful. If the "set
> codec" operation is separate from "set profile" operation, then you no
> doubt will ask how to implement the client API for this new operation,
> and I don't have a very good answer.
>
> Georg Chini has been working on a new messaging API, which would be a
> good fit for this, but that's stalled (I don't remember if it's waiting
> for review or a new version of the patches).

It has been waiting for a new version. Meanwhile I got around
to work on this again and will probably send a new patch set
in a couple of days.

> If you don't want to be
> blocked by that, the alternative is to add new "get bluetooth card
> info" and "set bluetooth card a2dp codec" commands to the core protocol
> (the card info command would be for enumerating the available codecs),
> or to add the commands via a new "protocol extension" similar to what
> module-stream-restore, module-device-restore and module-device-manager
> do. I would be fine with either approach.
>
> Adding new commands to the core protocol would be somewhat simpler, but
> I'm not sure other maintainers are ok with adding bluetooth specific
> functionality to the core protocol.
>