Call audio keeps routing back to Bluetooth

Bug Reports
,
1

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
2

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

3

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).

4

Which Bluetooth device are you using?

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

5

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

6

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.

7

Thanks for the report @attah, and for the followup info. I’ve created an internal issue for this and tagged it as “tracked”.

As always, if there’s progress to report back, I’ll do my best to add it here.

1 Like