Hi Kim, The AGL audio stack uses bluez-alsa (https://github.com/Arkq/bluez-alsa) that is designed to interface to bluez and ofono (basically, with a communication libraries and dbus events) In 4a-hal-generic, there is a bluez-alsa audio plugin: (see https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/4a-hal-generic.git;a=tree;f=plugins/lib/bluealsa;h=f52c15fdf412926d4da913a3fcb812d5380beae9;hb=HEAD) that makes the glue between the incoming a2dp/hfp (aka sco) transports, and the audio streams that the 4a-softmixer must handle. bluez-alsa implements alsa-pcm plugins that are then opened by the softmixer, with the transport information as parameters. IMHO, the best design approach, I mean, the one that would impact less layers, would be to write a BSA plugin in the 4a-hal-generic. The condition is obviously that the BSA stack provides Alsa PCM, else, you will also have to write them. The agl-service-bluetooth is not aware of the audio streams, its role is basically to handle the connectivity. Hope this helps, Thierry On 05/28/2019 10:57 AM, Do-Hoon, Kim
wrote:
|
_______________________________________________ automotive-discussions mailing list automotive-discussions@xxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions