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
