Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how can an SCO link be reestablished after it has been disconnected by the HF device? #699

Closed
Sleepalltheday opened this issue Apr 28, 2024 · 3 comments

Comments

@Sleepalltheday
Copy link

Problem

  • I have observed that during interactions with certain headset devices using the HFP (Hands-Free Profile), the headset devices tend to disconnect the SCO link upon receiving the call termination indication ("CIEV:2,0").
  • After the SCO link is disconnected, bluez-alsa does not automatically initiate a reconnection, and I have not discovered a relevant D-Bus interface to prompt bluez-alsa to establish an SCO connection again.
  • I tried using the "SelectCodec" feature to renegotiate the audio encoding, but when bluez-alsa sees the codec hasn't changed, it doesn't do anything.
  • In this case, how can I prompt bluez-alsa to re-establish the SCO connection?

Reproduction steps

  • bluealsa -p hfp-ag -p a2dp-source
  • use bluetoothctl connect to HF device
  • run bluealsa-rfcomm, make the call setup "CIEV:2,1"
  • send the call end "CIEV:2,0"

Setup

  • linux 5.1
  • bluealsa --version
    • v4.1.1
  • bluetoothd --version
    • 5.56

Additional context

  • After a call finishes, the SCO connection gets closed down
bluealsa: D: ba-rfcomm.c:110: Sending AT message: RAW: command:
+BSIR:0
, value:(null)
bluealsa: D: ba-rfcomm.c:110: Sending AT message: RAW: command:
+CIEV:3,3
, value:(null)
bluealsa: D: ba-rfcomm.c:110: Sending AT message: RAW: command:
+CIEV:2,1
, value:(null)
bluealsa: D: ba-rfcomm.c:110: Sending AT message: RAW: command:
+CIEV:3,0
, value:(null)
bluealsa: D: ba-rfcomm.c:110: Sending AT message: RAW: command:
+CIEV:2,0
, value:(null)
bluealsa: D: at.c:179: AT message: CMD: command:+CLCC, value:(null)
bluealsa: D: ba-rfcomm.c:110: Sending AT message: RAW: command:
OK
, value:(null)


bluealsa: D: io.c:46: BT socket disconnected: Connection reset by peer
bluealsa: D: ba-transport.c:462: Closing BT socket duplicate [29]: 31
bluealsa: D: sco.c:504: IO loop: EXIT: sco_msbc_dec_thread: HFP Audio Gateway (mSBC)
bluealsa: D: ba-transport.c:1983: Exiting IO thread [ba-sco-dec]: HFP Audio Gateway (mSBC)
bluealsa: D: ba-transport.c:462: Closing BT socket duplicate [29]: 30
bluealsa: D: ba-transport.c:903: Releasing SCO link: 29
bluealsa: D: ba-transport.c:1983: Exiting IO thread [ba-sco-enc]: HFP Audio Gateway (mSBC)
@Sleepalltheday
Copy link
Author

I found that opening the PCM channel can establish the SCO connection, so should I proceed with this approach?

@borine
Copy link
Collaborator

borine commented Apr 29, 2024

I found that opening the PCM channel can establish the SCO connection

When using BlueALSA, that is in fact the only way to establish the SCO connection. There is an example in the wiki of using bluealsa-rfcomm to simulate a phone transferring call audio to a hands-free device; see RFCOMM with HFP, or if you are using an ALSA application you can use a PCM plugin to take care of the rfcomm messages for you; see HFP AG Helper Plugin for BlueALSA

@borine
Copy link
Collaborator

borine commented Aug 13, 2024

closing due to lack of activity

@borine borine closed this as completed Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants