Call audio keeps routing back to Bluetooth

REPRODUCIBILITY: TBD, several times in one call so far
OS VERSION: 4.4.0.64
HARDWARE: Xperia 10 III
UI LANGUAGE: Swedish
REGRESSION: Yes

DESCRIPTION:

Call audio keeps getting routed back to Bluetooth after manually routing to normal earpiece.

PRECONDITIONS:

VoLTE enabled (probably not super relevant).

STEPS TO REPRODUCE:

  1. Get a call
  2. In the in-call view, route audio to earpiece by unchecking the headset indicator
  3. Optional: Lock screen to make doubly sure it is not accidental touch doing it

EXPECTED RESULT:

Call stays on earpiece

ACTUAL RESULT:

Call is routed back to Bluetooth after a few seconds

MODIFICATIONS:

None

ADDITIONAL INFORMATION:

2 Likes

Semi-reproduced today… i got just the hangup tone routed to headphones. For the call itself the routing setting stayed as i set it.

Shameless bump. This reproduces very often.
@pherjung pretty please?

It is doubly annoying because microphones on headsets tends to be borked on Sailfish (and Linux in general).

Which Bluetooth device are you using?

May I ask you to provide some logs?
Thank you in advance :slight_smile:

Currently Sony LinkBuds, but it does not seem to be limited to that specific device.

Tried reproducing with an outgoing call, and it didn’t seem to happen then.

But when i hang up, i get that tone through the headset, and this log:
pulseaudio[5881]: E: [pulseaudio] classify.c: could not find group

After having experienced this a couple of more times, i have found that it is not a 100% reproducible problem - more like 50%, and that is in my case.

Some more pieces of log that looks somewhat relevant (everything else says kernel):

nov 29 17:50:11 Xperia10III ofonod[3338]: Server: < AT+BCC\r
nov 29 17:50:11 Xperia10III ofonod[3338]: Server: > \r\nOK\r\n
nov 29 17:50:11 Xperia10III kernel: sec_ts 1-0048: [sec_input] [R] tID:0 mc:16 tc:2 lx:869 ly:173 v:0100 cal:A2 id(0,0) p:0 noise:0 lp:(0)
nov 29 17:50:11 Xperia10III dbus-daemon[2112]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.68" (uid=100000 pid=5881 comm="/usr/bin/pulseaudio --daemonize=no -n --file=/etc/" label="u:r:kernel:s0") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.13" (uid=0 pid=3338 comm="/usr/sbin/ofonod -n --nobacktrace --noplugin=,he91" label="u:r:kernel:s0")
nov 29 17:50:11 Xperia10III dbus-daemon[2112]: dbus-daemon[2112]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.68" (uid=100000 pid=5881 comm="/usr/bin/pulseaudio --daemonize=no -n --file=/etc/" label="u:r:kernel:s0") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.13" (uid=0 pid=3338 comm="/usr/sbin/ofonod -n --nobacktrace --noplugin=,he91" label="u:r:kernel:s0")
nov 29 17:50:11 Xperia10III mce[1996]: modules/audiorouting.c: audio_route_sink(): unknown audio sink device = 'bthfpforcall'
nov 29 17:50:11 Xperia10III mce[1996]: modules/audiorouting.c: audio_route_sink(): unknown audio sink device = 'bthfpforcall'
nov 29 17:50:11 Xperia10III kernel: sec_ts 1-0048: [sec_input] [P] tID:0 x:861 y:180 z:63 major:49 minor:41 tc:3 type:0 noise:0
nov 29 17:50:11 Xperia10III ofonod[3338]: Server: < AT+VGS=8\r
nov 29 17:50:11 Xperia10III ofonod[3338]: Server: > \r\nOK\r\n

One possibility could be that the headset is a bit flaky (which it certainly is) and triggers automatic re-routing as if it had just been connected.
A suggestion would be to disable all automatic switching, at least to Bluetooth, after the user has switched manually.