Implement a genuine bluezalsa client in a 4a plugin

Description

The coming version of 4a implements the bluetooth audio support, by opening an ioplug PCM, provided by a hacked version of bluez-alsa. For now, only playback is supported.

The hacked version masks the complexity of devices connections/disconnections, so that PCM is always reading for reading sound, and thus it works without modifying the sofmixer too much.

This works but has several inconveniences and limitations

  • there is no chance to have the hacked version of bluez-alsa accepted on mainline

  • only one PCM is allowed

  • the bluetooth adapter must be hci0, some non negligeable work would be needed to fix that.

The idea is modify bluez-alsa the proper way, ie, by creating a shared library (static or not) to link 4a with.

The place where the devices connections/disconnections will be handled is to be defined. The shared library must be small and smart enough to avoid to link the HAL with libasound.

Ideally, just like in the current version, the softmixer should not be aware of the connected devices.

Moreover (this has to be designed as well), an extra copy loop for the sound frames should be avoided.

Environment

None

blocks

Activity

Show:

Thierry Bultel 
September 4, 2018 at 10:08 AM

In order to be hopefully merged on mainline, the improvement will be implemented on top of latest bluezalsa mainline version.

This will require a bump of bluez in yocto, since the transport level API seems to have changed.

Fixed

Details

Assignee

Reporter

Fix versions

Labels

Contract ID

Components

Affects versions

Priority

Created September 4, 2018 at 8:53 AM
Updated January 23, 2019 at 3:23 AM
Resolved December 20, 2018 at 4:36 PM