Sure!
Linux Kernel: 4.4.11-v7+
Bluez 5.39
PA: 8.0
Ofono : 1.18
Bus 001 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd
Bluetooth Dongle (HCI mode)
hci1: Type: BR/EDR Bus: USB
BD Address: 00:1A:7D:DA:71:13 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:997282 acl:2321 sco:7085 events:417 errors:0
TX bytes:369146 acl:198 sco:7083 commands:138 errors:1
Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'CarPi #2'
Class: 0x2c0000
Service Classes: Rendering, Capturing, Audio
Device Class: Miscellaneous,
HCI Version: 4.0 (0x6) Revision: 0x22bb
LMP Version: 4.0 (0x6) Subversion: 0x22bb
Manufacturer: Cambridge Silicon Radio (10)
On Wed, Jul 27, 2016 at 7:29 PM, Matthew Waddell <matt@xxxxxxxxxxxxxx> wrote:
> Hi Jason,
>
> Thank you for the success report!
>
> Would you be able to share the version numbers of the Kernel, Bluez, Ofono,
> and pulseaudio you are using on your pi3? Also, do you know what chipset of
> bluetooth adapter you are using?
>
> Thanks!
> _matt
>
> On 07/27/2016 04:25 PM, Jason Gauthier wrote:
>>
>> Matthew,
>>
>> That was my original email, but no success. The BT adapter in the
>> raspberry pi 3 I was using does not show any SCO packets during the
>> call. I've moved to an external BT device and I haven't had any
>> issues with it.
>>
>> When the call is made, your screen should be *flooded* with SCO
>> packets. If not, then you are experiencing the same problem that I've
>> never found a solution to.
>>
>> Good luck,
>>
>> Jason
>>
>> On Wed, Jul 27, 2016 at 4:09 PM, Matthew Waddell <matt@xxxxxxxxxxxxxx>
>> wrote:
>>>
>>> Hi,
>>>
>>> I am trying to configure HFP to allow in-call audio to be routed through
>>> my
>>> PC's audio card. I'm interested to know the current state of support,
>>> and
>>> if anyone has had success in getting it to work. I have tried various
>>> combinations of the following components, but have so far been unable to
>>> get
>>> the in-call audio working:
>>>
>>> Kernel: 4.4.11, 4.6.4, 4.7 (unstable)
>>> Bluez: 5.37, 5.7, 5.8, 5.9
>>> Pulesaudio: 7, 8, 9
>>> Ofono: 1.7, 1.8, 1.9
>>> USB Bluetooth Adapters:
>>> 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (CSR8510
>>> A10)
>>> 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0 (with firmware
>>> 001.002.014 build 1338)
>>>
>>> I've can verify that ofono is able to detect the HFP capabilities of a
>>> connected device, and to establish a 'modem' to it. Pulseaudio is also
>>> notified when a call becomes active, and appears to load the appropriate
>>> loopbacks to route the audio from/to the call through the HFP modem.
>>> Hacking
>>> in some extra debug tracing to pulseaudio, I've verified that pulseaudio
>>> receives SCO packets from the file descriptor that it receives from
>>> ofono.
>>> Still, I am unable to hear any audio from the call.
>>>
>>> Something interesting that I've noticed, however, is that if I look at
>>> the
>>> in-call traffic with hcidump, it looks to me like the payloads of each of
>>> the SCO packets that are received from the remote device (the phone) are
>>> either all 0x0000 or 0x0001. I have not seen cases where it is anything
>>> other than that.
>>>
>>> Does anyone have any suggestions for what might be going on, or how I
>>> might
>>> be able to debug this further?
>>>
>>> This post from May sounds like similar circumstances, and possibly even a
>>> success story:
>>> http://www.spinics.net/lists/linux-bluetooth/msg67283.html
>>>
>>>
>>> Thanks!
>>> _matt
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-bluetooth"
>>> in
>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
