Random audio drops on wired headphones - plays from top speaker instead

Bug Reports
#1

REPRODUCIBILITY: 50% (sometimes)
OSVERSION: 4.4.0.68
HARDWARE: Sony Xperia 10 III - xqbt52 - xqbt52 - 1.0.0.142 - aarch64
UI LANGUAGE: English (US) (user: en_US, os: en_US.utf8)
REGRESSION: yes (since: 4.4.0.64 - aarch64)

DESCRIPTION:

Random audio drops on wired headphones - plays from top speaker instead

PRECONDITIONS:

STEPS TO REPRODUCE:

  1. Occurs at random

EXPECTED RESULTS:

Audio should not leave headphone channel when in use.

ACTUAL RESULTS:

Occasional drops of wired headphone audio connection.

MODIFICATIONS:

  • Patchmanager: yes
  • OpenRepos: yes
  • Chum: yes
  • Other: no:

ADDITIONAL INFORMATION:

Device Owner User: defaultuser
Home Encryption: enabled

the initial version of this bug report was created using Bugger 0.9.8+git1
1 Like
#2

Have you considered that your headphones and/or phone may have developed a bad connection?

#3

Unplugging and replugging redirects audio back to the earpiece, but a reboot fixes the issue…

#4

I have the same problem, and it happened with at least two different headphones, a pair of Sennheiser in-ear without microphone (product label no longer readable) and brand new Sony MH750 with built-in microphone (They probably came with one of my earlier Sony cell phones, I started to use them because I first thought the dismantling cable of my Sennheiser would cause the problem).
Plugging the headphones in and out seems to change the volume level of the upper speaker when the problem happens, but it doesn’t solve the problem.

Is there something I can do to help track down this bug when it happens next time?

It happened again today, I collected some kernel messages, but I don’t know if they are relevant.

Further Investigation: When I plug out the headphone, gPodder stops playing, when I resume playing and plug the headphones back in, the volume will change according to the different volume settings for speaker and headphones, BUT it still plays from the speaker.

Should I report this as a regular Bug?

#5

I wonder if the sink just randomly fails and tries to reset itself…

#6

I’ve had the same issue happen on Bluetooth through my car radio, so maybe it’s something bigger?

#7

It just happened again to me, could someone from Jolla please advice what would help them most to track the root cause of this problems?

Following the output of dmesg from the screen turning off (due to power saving), then activated (because I plugged in the headphones) until it turned off again (The time in dmesg is completely wrong, but I don’t know the reason, system time is correct):

[Mo Okt  3 08:49:04 2022] @@@@ panel power off @@@@
[Mo Okt  3 08:49:08 2022] [drm:dsi_display_set_mode] [msm-dsi-info]: mdp_transfer_time_us=15666 us
[Mo Okt  3 08:49:08 2022] [drm:dsi_display_set_mode] [msm-dsi-info]: hactive= 1080,vactive= 2520,fps=60
[Mo Okt  3 08:49:08 2022] [drm:dsi_ctrl_isr_configure] [msm-dsi-info]: dsi-ctrl-0: IRQ 385 registered
[Mo Okt  3 08:49:08 2022] dsi_panel_driver_touch_pinctrl_set_state: invalid 'somc_ts_int_active' pinstate
[Mo Okt  3 08:49:08 2022] @@@@ panel power on @@@@
[Mo Okt  3 08:49:08 2022] somc_panel_color_manager: somc_panel_inject_crtc_overrides (786): Override: Already have original funcs! Is setup called twice??
[Mo Okt  3 08:49:08 2022] somc_panel_color_manager: somc_panel_pcc_setup (884): Cannot read uv data: missing command
[Mo Okt  3 08:49:08 2022] somc_panel_color_manager: somc_panel_pcc_setup (888): u,v is flashed 0.
[Mo Okt  3 08:49:08 2022] somc_panel_color_manager: somc_panel_colormgr_apply_calibrations: Couldn't apply PCC calibration
[Mo Okt  3 08:49:08 2022] somc_panel_color_manager: somc_panel_colormgr_apply_calibrations: Cannot send HSIC calibration
[Mo Okt  3 08:49:08 2022] sec_ts 1-0048: [sec_input] sec_ts_dsi_panel_notifier_cb: power up
[Mo Okt  3 08:49:08 2022] sec_ts 1-0048: [sec_input] sec_ts_start_device
[Mo Okt  3 08:49:08 2022] sec_ts 1-0048: [sec_input] sec_ts_pinctrl_configure: ACTIVE
[Mo Okt  3 08:49:08 2022] (NULL device *): deviceless supply vdd not found, using dummy regulator
[Mo Okt  3 08:49:08 2022] (NULL device *): deviceless supply avdd not found, using dummy regulator
[Mo Okt  3 08:49:08 2022] sec_ts 1-0048: [sec_input] sec_ts_power: on: avdd:on, dvdd:on
[Mo Okt  3 08:49:08 2022] dsi_panel_driver_oled_short_det_handler: VREG_NG interrupt!
[Mo Okt  3 08:49:09 2022] sec_ts 1-0048: [sec_input] sec_ts_wait_for_ready: 09, 00, 10, 00, 00, 00, 00, 00 [0]
[Mo Okt  3 08:49:09 2022] sec_ts 1-0048: [sec_input] sec_ts_start_device: cover open, not send cmd
[Mo Okt  3 08:49:09 2022] sec_ts 1-0048: [sec_input] sec_ts_set_grip_type: re-init grip(0), edh:0, edg:0, lan:0
[Mo Okt  3 08:49:09 2022] sec_ts 1-0048: [sec_input] sec_ts_read_event: STATUS 1d 61 2 2 3 0 0 0
[Mo Okt  3 08:49:09 2022] rpmh_rsc_send_data: 92 callbacks suppressed
[Mo Okt  3 08:49:09 2022] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x30010
[Mo Okt  3 08:49:09 2022] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x30010
[Mo Okt  3 08:49:09 2022] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x30010
[Mo Okt  3 08:49:09 2022] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x30010
[Mo Okt  3 08:49:09 2022] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x30010
[Mo Okt  3 08:49:09 2022] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x30010
[Mo Okt  3 08:49:09 2022] pn544_dev_ioctl :enter cmd = 1074063617, arg = 0
[Mo Okt  3 08:49:09 2022] pn544_dev_ioctl power off
[Mo Okt  3 08:49:09 2022] pn544_dev_ioctl :exit cmd = 1074063617, arg = 0
[Mo Okt  3 08:49:09 2022] pn544_dev_ioctl :enter cmd = 1074063617, arg = 1
[Mo Okt  3 08:49:09 2022] pn544_dev_ioctl power on
[Mo Okt  3 08:49:09 2022] pn544_dev_ioctl :exit cmd = 1074063617, arg = 1
[Mo Okt  3 08:49:09 2022] droid-hal-init: processing action (ril.ecclist=*) from (/usr/libexec/droid-hybris/system/etc/init/ecclist.rc:6)
[Mo Okt  3 08:49:09 2022] droid-hal-init: processing action (ril.ecclist=*) from (/usr/libexec/droid-hybris/system/etc/init/ecclist.rc:6)
[Mo Okt  3 08:49:09 2022] droid-hal-init: processing action (ril.ecclist1=*) from (/usr/libexec/droid-hybris/system/etc/init/ecclist.rc:10)
[Mo Okt  3 08:49:11 2022] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x30010
[Mo Okt  3 08:49:11 2022] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x30010
[Mo Okt  3 08:49:11 2022] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x30010
[Mo Okt  3 08:49:11 2022] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x30010
[Mo Okt  3 08:49:11 2022] sec_ts 1-0048: [sec_input] sec_ts_dsi_panel_notifier_cb: power down
[Mo Okt  3 08:49:11 2022] (NULL device *): deviceless supply vdd not found, using dummy regulator
[Mo Okt  3 08:49:11 2022] (NULL device *): deviceless supply avdd not found, using dummy regulator
[Mo Okt  3 08:49:11 2022] sec_ts 1-0048: [sec_input] sec_ts_power: off: avdd:on, dvdd:on
[Mo Okt  3 08:49:11 2022] sec_ts 1-0048: [sec_input] sec_ts_pinctrl_configure: SUSPEND
[Mo Okt  3 08:49:11 2022] Entering OFF state from 0
[Mo Okt  3 08:49:11 2022] AOD mode OFF
[Mo Okt  3 08:49:12 2022] pn544_dev_ioctl :enter cmd = 1074063617, arg = 0
[Mo Okt  3 08:49:12 2022] pn544_dev_ioctl power off
[Mo Okt  3 08:49:12 2022] pn544_dev_ioctl :exit cmd = 1074063617, arg = 0
[Mo Okt  3 08:49:12 2022] @@@@ panel power off @@@@
#8

Found it happened to me again when I got an email from the main system with audio playing in spotify…

#9

I still fail to see a clear pattern behind this. The problem appears out of a sudden, and sometimes disappears. Yesterday, it seems to have started after the phone was playing a notification, while I was listening to a podcast.
The only uncommon software installed on my device which could interfere with audio in some unusual way is RingingRestorer.

2 Likes
#10

This is now also affecting my alarm clock (the device vibrates, but doesn’t play an alarm on the speaker), which really renders my device unsuitable for regular use (I can’t rely on it waking me up in the morning like it is supposed to do). Is there some advice how to debug this?

#11

That’s strange. What are the values of Setting->Sounds & Reaction?
Is an ambiance set with no sound? If yes, see this bug.

#12

That’s strange. What are the values of Setting->Sounds & Reaction?

Looks normal to me, “do not disturb” is not activated, but I can’t tell how it looked when the bug happened (I had to restart the device in order to bring it back to normal working order).

Is an ambiance set with no sound? If yes, see this bug.

I haven’t swiched ambience since many weeks, thus I don’t think this bug applies here.

#13

I think it occurs when one audio event tries to occur during another

#14

Fairly possible, it probably just happened when I had gpodder paused with headphones plugged in, and fernschreiber (telegram client) played a notification. A bit later I wanted to resume playing the podcast, and it played from the speaker. Plugging in and removing the headphones again didn’t help.

1 Like
#15

Same issue, different feeds when idle, expectation to swap back to headphones doesn’t work.

#16

For me, it’s E-Mail and Spotify

#17

Same issue, reboot solves it, very annoying issue.

1 Like