As you know, the bsa stack is a commercial stack.
So, I think I use the bsa stack instead of bluez in the sense that it's easy to get tech support if I have a problem with the bluetooth stack.
Of course, as you said, the current version of the bluez stack would be satisfactory.
So, I think I use the bsa stack instead of bluez in the sense that it's easy to get tech support if I have a problem with the bluetooth stack.
Of course, as you said, the current version of the bluez stack would be satisfactory.
2019년 5월 28일 (화) 오후 7:03, Thierry Bultel <thierry.bultel@xxxxxxx>님이 작성:
Please tell us about your progress.
By the way, would you mind saying two words about the advantage of BSA vs Bluez ?
I am masking because AFAIK the current version of Bluez is rather satisfying, stable enough
all the tests I made did not raise any bugs. (Though it might have been the case in the old past ...)
Thanks !
On 05/28/2019 11:35 AM, Do-Hoon, Kim wrote:
Thank you for your advice. Thierry.
I will proceed as advised. :D
2019년 5월 28일 (화) 오후 6:19, Thierry Bultel <thierry.bultel@xxxxxxx>님이 작성:
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
Cell : 010-4723-0479---------------------------------------
_______________________________________________ automotive-discussions mailing list automotive-discussions@xxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
automotive-discussions mailing list
automotive-discussions@xxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
--
---------------------------------------DrimAES - DoHoon.Kim
Cell : 010-4723-0479---------------------------------------
---------------------------------------
DrimAES - DoHoon.KimCell : 010-4723-0479
---------------------------------------
_______________________________________________ automotive-discussions mailing list automotive-discussions@xxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
