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:
Hi!
We modified the agl-service-bluetooth in AGL Rootfs to
implement a2dp, hfp, and pbap functions. Using the bsa
bluetooth stack.
And I'm having trouble designing the audio interface.
Is there a way to connect a device connected via
agl-service-bluetooth to an existing audio system such
as alsa or pulseaudio?
--
---------------------------------------
DrimAES - DoHoon.Kim
---------------------------------------
_______________________________________________
automotive-discussions mailing list
automotive-discussions@xxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
