SCO / eSCO support

[crisstinab]

Hello,

I am having troubles testing phone calls in a setup that involves Bumble (hci_bridge.py as a controller) + Android Automotive in a virtualized environment with Cuttlefish. I am not using the latest AOSP version but and older one, Android 14 r28 in case it matters.

I have started to debug why I am unable to hear audio calls with this setup and the first step would be to check if Bumble is sending SCO / eSCO packets via the controller or if there is support for these.

I have noticed some traces in Bumble during an audio call:

INFO:bumble.bridge:[CONTROLLER->HOST] HCI_CONNECTION_REQUEST_EVENT:
  bd_addr:         FC:AA:81:BF:85:45/P
  class_of_device: 0
  link_type:       eSCO
 
 
INFO:bumble.bridge:[CONTROLLER->HOST] HCI_SYNCHRONOUS_CONNECTION_COMPLETE_EVENT:
  status:                HCI_CONNECTION_ACCEPT_TIMEOUT_ERROR
  connection_handle:     0
  bd_addr:               FC:AA:81:BF:85:45/P
  link_type:             eSCO
  transmission_interval: 0
  retransmission_window: 0
  rx_packet_length:      0
  tx_packet_length:      0
  air_mode:              Transparent Data

For starting Bumble I am doing it like this:

sudo BUMBLE_LOGLEVEL=DEBUG python bumble/apps/hci_bridge.py android-netsim:_:7300,mode=controller hci-socket:0

Would Bumble be able to send SCO packets that would be processed by the BT stack / Audio on Android side?
If yes, do you have any ideas on how to debug this / check at Bumble level if these packets are forwarded or not or if they are not accepted by the Host somehow?

[zxzxwu]

Since you can see connection request events, hci_bridge should have forwarded the packets. The host sounds like a Cuttlefish, so what you can try is:

1. Enable snoop on CF to see if it receives the packets.
2. Check logcat to see why Android host doesn't accept SCO.