# No sound in voice calls after a few days **URL:** \ **Category:** General\ **Created:** [February 1, 2026, 10:45am UTC](https://forum.droidian.org/t/no-sound-in-voice-calls-after-a-few-days/68 "2026-02-01T10:45:35Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![boroli](https://forum.droidian.org/letter_avatar_proxy/v4/letter/b/e36b37/32.png) [@boroli](https://forum.droidian.org/u/boroli)\ **Post date:** [February 1, 2026, 10:45am UTC](https://forum.droidian.org/t/no-sound-in-voice-calls-after-a-few-days/68/1 "2026-02-01T10:45:35Z")
I’m using Droidian on a Vollaphone 22. After flashing the phone, normal audio calls work out of the box. But after a day or a few, I can’t hear anything while making a phone call, and the person on the other end likewise. The same goes if I receive a call. Only a faintly low frequent buzzing is noticeable on both ends. What I tried / checked to get it working again: - Sound works in general. I can test the sound, and I hear the phone ringing when Feedback settings for Calls and Profile is on Full - If the other person hangs up I hear three beep, beep, beep - VoIP accounts are affected too - Doesn’t matter if output is to earpiece or speaker, both don’t show any effect - pactl settings checked, and changed quite a few, but with no effect at all - Rebooted the modem: `sudo mmcli -m any -r` with no effect - Rebooted the phone - Turned the phone off and removed battery to be sure the modem doesn’t hang - Set modem specifically to 2G, 3G - Tried droidian version 101 and 102 Nothing had any effect. I’m always ending up flashing my phone again after a few days. Then I can make calls again. It’s frustrating, because I know in general it’s working, but the error here is none obvious. Does anyone had similar issues? Or maybe just some ideas what could go possibly wrong? Sounds to me like a problem with pipewire routing, but that’s just a guess. ---
**Author:** ![arpio](https://forum.droidian.org/user_avatar/forum.droidian.org/arpio/32/45_2.png) [@arpio](https://forum.droidian.org/u/arpio)\ **Post date:** [February 1, 2026, 6:22pm UTC](https://forum.droidian.org/t/no-sound-in-voice-calls-after-a-few-days/68/2 "2026-02-01T18:22:55Z")
Are you sure its only after day or two? For me on different device only happens if I restart phosh without reboot. ---
**Author:** ![eugenio](https://forum.droidian.org/user_avatar/forum.droidian.org/eugenio/32/36_2.png) [@eugenio](https://forum.droidian.org/u/eugenio)\ **Post date:** [February 3, 2026, 11:32pm UTC](https://forum.droidian.org/t/no-sound-in-voice-calls-after-a-few-days/68/3 "2026-02-03T23:32:56Z")
Could you post ofono logs when trying calling? ```auto sudo journalctl --no-pager -xe -u ofono ``` (please check and scrub eventual sensitive data) ---
**Author:** ![boroli](https://forum.droidian.org/letter_avatar_proxy/v4/letter/b/e36b37/32.png) [@boroli](https://forum.droidian.org/u/boroli)\ **Post date:** [February 4, 2026, 9:16pm UTC](https://forum.droidian.org/t/no-sound-in-voice-calls-after-a-few-days/68/4 "2026-02-04T21:16:16Z")
Here are my logs of ofono. The first four times I tried calling, while during the last two lines I received a call. Anything else you need? ```auto Feb 04 21:48:22 VollaPhone22 ofonod[3381]: ofonod[3381]: dialing "" Feb 04 21:48:22 VollaPhone22 ofonod[3381]: dialing "" Feb 04 21:48:57 VollaPhone22 ofonod[3381]: ofonod[3381]: Call 1 ended with cause 16 -> ofono reason 2 Feb 04 21:48:57 VollaPhone22 ofonod[3381]: Call 1 ended with cause 16 -> ofono reason 2 Feb 04 21:50:45 VollaPhone22 ofonod[3381]: ofonod[3381]: Call 1 ended with cause 16 -> ofono reason 2 Feb 04 21:50:45 VollaPhone22 ofonod[3381]: Call 1 ended with cause 16 -> ofono reason 2 ``` ---
**Author:** ![boroli](https://forum.droidian.org/letter_avatar_proxy/v4/letter/b/e36b37/32.png) [@boroli](https://forum.droidian.org/u/boroli)\ **Post date:** [February 4, 2026, 9:24pm UTC](https://forum.droidian.org/t/no-sound-in-voice-calls-after-a-few-days/68/5 "2026-02-04T21:24:05Z")
I haven’t found out what actually triggered it. Could likely be that it is a restart of phosh without reboot. But do you recover it? Just simply by rebooting the phone completely? ---
**Author:** ![eugenio](https://forum.droidian.org/user_avatar/forum.droidian.org/eugenio/32/36_2.png) [@eugenio](https://forum.droidian.org/u/eugenio)\ **Post date:** [February 8, 2026, 11:05pm UTC](https://forum.droidian.org/t/no-sound-in-voice-calls-after-a-few-days/68/6 "2026-02-08T23:05:58Z")
Thank you. Sorry, I missed one crucial part, which is to enable Debug logging (apologies for that - I have it enabled on various devices) ```auto sudo systemctl edit ofono ``` add ```auto [Service] ExecStart= ExecStart=/usr/sbin/ofonod --nodetach -d * ``` save, then ```auto sudo systemctl restart ofono ``` to disable: ```auto sudo rm -f /etc/systemd/system/ofono.service.d/override.conf sudo systemctl daemon-reload sudo systemctl restart ofono ``` it will be rather verbose, though. And please double check the output as there might be sensible data indeed. There are various layers on the Droidian telephony. Perhaps you might try restarting the ofono service and ofono2mm (which replaces the ModemManager service): ```auto sudo systemctl restart ofono sudo systemctl restart ModemManager ``` ---
**Author:** ![boroli](https://forum.droidian.org/letter_avatar_proxy/v4/letter/b/e36b37/32.png) [@boroli](https://forum.droidian.org/u/boroli)\ **Post date:** [February 9, 2026, 8:34pm UTC](https://forum.droidian.org/t/no-sound-in-voice-calls-after-a-few-days/68/7 "2026-02-09T20:34:55Z")
Got you. After enabling debug mode, I got the following logs. Now I understand what you mean by rather verbose. In total I’ve logs of three calls, coming and going. Just showing here one. Hope that helps: ```auto Feb 09 21:20:55 VollaPhone22 ofonod[3393]: ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:20:55 VollaPhone22 ofonod[3393]: ofonod[3393]: plugins/upower.c:update_battery_level() last_battery_level: 0 battery_level: 4 (75.000000) Feb 09 21:20:55 VollaPhone22 ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:20:55 VollaPhone22 ofonod[3393]: plugins/upower.c:update_battery_level() last_battery_level: 0 battery_level: 4 (75.000000) Feb 09 21:21:00 VollaPhone22 ofonod[3393]: ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:21:00 VollaPhone22 ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:21:05 VollaPhone22 ofonod[3393]: ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:21:05 VollaPhone22 ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:21:10 VollaPhone22 ofonod[3393]: ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:21:10 VollaPhone22 ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:21:15 VollaPhone22 ofonod[3393]: ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:21:15 VollaPhone22 ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:21:45 VollaPhone22 ofonod[3393]: ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:21:45 VollaPhone22 ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:21:50 VollaPhone22 ofonod[3393]: ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:21:50 VollaPhone22 ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:21:55 VollaPhone22 ofonod[3393]: ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:21:55 VollaPhone22 ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:22:00 VollaPhone22 ofonod[3393]: ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:22:00 VollaPhone22 ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 6f 00 00 9e 00 00 00 io...... Feb 09 21:22:04 VollaPhone22 ofonod[3393]: slot1 < 130 responseAcknowledgement Feb 09 21:22:04 VollaPhone22 ofonod[3393]: slot1 > [0000009e] 140 getCurrentCallsResponse_1_2 Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 32 3a 3a 49 52 61 64 .radio@1 .2::IRad Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0020: 69 6f 52 65 73 70 6f 6e 73 65 00 00 85 2a 74 70 ioRespon se...*tp Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0030: 00 00 00 00 c0 20 14 9a 7f 00 00 00 0c 00 00 00 ..... .. ........ Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0050: 00 00 00 00 85 2a 74 70 00 00 00 00 d0 20 14 9a .....*tp ..... .. Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0060: 7f 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0070: 00 00 00 00 00 00 00 00 00 00 00 00 85 2a 74 70 ........ .....*tp Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0080: 01 00 00 00 e0 20 14 9a 7f 00 00 00 00 00 00 00 ..... .. ........ Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0090: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 00A0: 00 00 00 00 .... Feb 09 21:22:04 VollaPhone22 ofonod[3393]: slot1 < [0000009f] 19 getLastCallFailCause Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0020: 69 6f 00 00 9f 00 00 00 io...... Feb 09 21:22:04 VollaPhone22 ofonod[3393]: slot1 > [0000009f] 18 getLastCallFailCauseResponse Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0020: 69 6f 52 65 73 70 6f 6e 73 65 00 00 85 2a 74 70 ioRespon se...*tp Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0030: 00 00 00 00 c0 20 14 9a 7f 00 00 00 0c 00 00 00 ..... .. ........ Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0050: 00 00 00 00 85 2a 74 70 00 00 00 00 d0 20 14 9a .....*tp ..... .. Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0060: 7f 00 00 00 18 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0070: 00 00 00 00 00 00 00 00 00 00 00 00 85 2a 74 70 ........ .....*tp Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0080: 01 00 00 00 e8 20 14 9a 7f 00 00 00 13 00 00 00 ..... .. ........ Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0090: 00 00 00 00 01 00 00 00 00 00 00 00 08 00 00 00 ........ ........ Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 00A0: 00 00 00 00 .... Feb 09 21:22:04 VollaPhone22 ofonod[3393]: slot1 > 2 callStateChanged Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0020: 69 6f 49 6e 64 69 63 61 74 69 6f 6e 00 00 00 00 ioIndica tion.... Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0030: 01 00 00 00 .... Feb 09 21:22:04 VollaPhone22 ofonod[3393]: slot1 < [000000a0] 10 getCurrentCalls Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0020: 69 6f 00 00 a0 00 00 00 io...... Feb 09 21:22:04 VollaPhone22 ofonod[3393]: slot1 < 130 responseAcknowledgement Feb 09 21:22:04 VollaPhone22 ofonod[3393]: slot1 > 18 callRing Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0020: 69 6f 49 6e 64 69 63 61 74 69 6f 6e 00 00 00 00 ioIndica tion.... Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0030: 01 00 00 00 01 00 00 00 85 2a 74 70 00 00 00 00 ........ .*tp.... Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0040: a0 20 14 9a 7f 00 00 00 04 00 00 00 00 00 00 00 . ...... ........ Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:04 VollaPhone22 ofonod[3393]: slot1 < 130 responseAcknowledgement Feb 09 21:22:04 VollaPhone22 ofonod[3393]: slot1 > 2 callStateChanged Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0020: 69 6f 49 6e 64 69 63 61 74 69 6f 6e 00 00 00 00 ioIndica tion.... Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0030: 01 00 00 00 .... Feb 09 21:22:04 VollaPhone22 ofonod[3393]: slot1 < 130 responseAcknowledgement Feb 09 21:22:04 VollaPhone22 ofonod[3393]: slot1 > [000000a0] 140 getCurrentCallsResponse_1_2 Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 32 3a 3a 49 52 61 64 .radio@1 .2::IRad Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0020: 69 6f 52 65 73 70 6f 6e 73 65 00 00 85 2a 74 70 ioRespon se...*tp Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0030: 00 00 00 00 48 21 14 9a 7f 00 00 00 0c 00 00 00 ....H!.. ........ Feb 09 21:22:04 VollaPhone22 ofonod[3393]: src/binder_voicecall.c:binder_voicecall_info_new() [id=1,status=4,type=0,number=,name=] Feb 09 21:22:04 VollaPhone22 ofonod[3393]: 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .......ofonod[3393]: src/binder_voicecall.c:binder_voicecall_info_new() [id=1,status=4,type=0,number=,name=] Feb 09 21:22:04 VollaPhone22 ofonod[3393]: ofonod[3393]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall event, status: incoming (4), id: 1, number: called_number: , called_name Feb 09 21:22:04 VollaPhone22 ofonod[3393]: ofonod[3393]: src/voicecall.c:ofono_voicecall_notify() Did not find a call with id: 1 Feb 09 21:22:04 VollaPhone22 ofonod[3393]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall event, status: incoming (4), id: 1, number: called_number: , called_name Feb 09 21:22:04 VollaPhone22 ofonod[3393]: src/voicecall.c:ofono_voicecall_notify() Did not find a call with id: 1 Feb 09 21:22:05 VollaPhone22 ofonod[3393]: ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:22:05 VollaPhone22 ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:22:08 VollaPhone22 ofonod[3393]: ofonod[3393]: src/binder_voicecall.c:binder_voicecall_info_new() [id=1,status=4,type=0,number=,name=] Feb 09 21:22:08 VollaPhone22 ofonod[3393]: src/binder_voicecall.c:binder_voicecall_info_new() [id=1,status=4,type=0,number=,name=] Feb 09 21:22:10 VollaPhone22 ofonod[3393]: ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:22:10 VollaPhone22 ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:22:11 VollaPhone22 ofonod[3393]: ofonod[3393]: src/binder_voicecall.c:binder_voicecall_answer() slot1 answering current call Feb 09 21:22:11 VollaPhone22 ofonod[3393]: src/binder_voicecall.c:binder_voicecall_answer() slot1 answering current call Feb 09 21:22:12 VollaPhone22 ofonod[3393]: . ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0050: 00 00 00 00 85 2a 74 70 00 00 00 00 58 21 14 9a .....*tp ....X!.. Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0060: 7f 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0070: 00 00 00 00 00 00 00 00 00 00 00 00 85 2a 74 70 ........ .....*tp Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0080: 01 00 00 00 68 21 14 9a 7f 00 00 00 60 00 00 00 ....h!.. ....`... Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0090: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 00A0: 00 00 00 00 85 2a 74 70 01 00 00 00 c8 21 14 9a .....*tp .....!.. Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 00B0: 7f 00 00 00 0e 00 00 00 00 00 00 00 02 00 00 00 ........ ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 00C0: 00 00 00 00 18 00 00 00 00 00 00 00 85 2a 74 70 ........ .....*tp Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 00D0: 01 00 00 00 d8 21 14 9a 7f 00 00 00 01 00 00 00 .....!.. ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 00E0: 00 00 00 00 02 00 00 00 00 00 00 00 30 00 00 00 ........ ....0... Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 00F0: 00 00 00 00 85 2a 74 70 01 00 00 00 00 00 00 00 .....*tp ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0100: 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 ........ ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0110: 00 00 00 00 48 00 00 00 00 00 00 00 ....H... .... Feb 09 21:22:12 VollaPhone22 ofonod[3393]: slot1 > 2 callStateChanged Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0020: 69 6f 49 6e 64 69 63 61 74 69 6f 6e 00 00 00 00 ioIndica tion.... Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0030: 01 00 00 00 .... Feb 09 21:22:12 VollaPhone22 ofonod[3393]: slot1 < [000000a1] 10 getCurrentCalls Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0020: 69 6f 00 00 a1 00 00 00 io...... Feb 09 21:22:12 VollaPhone22 ofonod[3393]: slot1 < 130 responseAcknowledgement Feb 09 21:22:12 VollaPhone22 ofonod[3393]: slot1 > 18 callRing Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0020: 69 6f 49 6e 64 69 63 61 74 69 6f 6e 00 00 00 00 ioIndica tion.... Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0030: 01 00 00 00 01 00 00 00 85 2a 74 70 00 00 00 00 ........ .*tp.... Feb 09 21:22:12 VollaPhone22 ofonod[3393]: src/binder_voicecall.c:binder_voicecall_info_new() [id=1,status=0,type=0,number=,name=] Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0040: 68 20 14 9a 7f 00 00 00 04 00 00 00 00 00 00 00 h ...... ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: slot1 < 130 responseAcknowledgement Feb 09 21:22:12 VollaPhone22 ofonod[3393]: slot1 > [000000a1] 140 getCurrentCallsResponse_1_2 Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 32 3a 3a 49 52 61 64 .radio@1 .2::IRad Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0020: 69 6f 52 65 73 70 6f 6e 73 65 00 00 85 2a 74 70 ioRespon se...*tp Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0030: 00 00 00 00 48 21 14 9a 7f 00 00 00 0c 00 00 00 ....H!.. ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0050: 00 00 00 00 85 2a 74 70 00 00 00 00 58 21 14 9a .....*tp ....X!.. Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0060: 7f 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0070: 00 00 00 00 00 00 00 00 00 00 00 00 85 2a 74 70 ........ .....*tp Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0080: 01 00 00 00 68 21 14 9a 7f 00 00 00 60 00 00 00 ....h!.. ....`... Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0090: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 00A0: 00 00 00 00 85 2a 74 70 01 00 00 00 c8 21 14 9a .....*tp .....!.. Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 00B0: 7f 00 00 00 0e 00 00 00 00 00 00 00 02 00 00 00 ........ ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 00C0: 00 00 00 00 18 00 00 00 00 00 00 00 85 2a 74 70 ........ .....*tp Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 00D0: 01 00 00 00 d8 21 14 9a 7f 00 00 00 01 00 00 00 .....!.. ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 00E0: 00 00 00 00 02 00 00 00 00 00 00 00 30 00 00 00 ........ ....0... Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 00F0: 00 00 00 00 85 2a 74 70 01 00 00 00 00 00 00 00 .....*tp ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0100: 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 ........ ........ Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0110: 00 00 00 00 48 00 00 00 00 00 00 00 ....H... .... Feb 09 21:22:12 VollaPhone22 ofonod[3393]: slot1 < [000000a2] 39 acceptCall Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0020: 69 6f 00 00 a2 00 00 00 io...... Feb 09 21:22:12 VollaPhone22 ofonod[3393]: slot1 > [000000a2] 38 acceptCallResponse Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:12 VollaPhone22 ofonod[3393]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall event, status: active (0), id: 1, number: called_number: , called_name Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:12 VollaPhone22 ofonod[3393]: 0020: 69 6f 52 65 ofonod[3393]: src/binder_voicecall.c:binder_voicecall_info_new() [id=1,status=0,type=0,number=,name=] Feb 09 21:22:12 VollaPhone22 ofonod[3393]: ofonod[3393]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall event, status: active (0), id: 1, number: called_number: , called_name Feb 09 21:22:12 VollaPhone22 ofonod[3393]: ofonod[3393]: src/voicecall.c:ofono_voicecall_notify() Found call with id: 1 Feb 09 21:22:12 VollaPhone22 ofonod[3393]: src/voicecall.c:ofono_voicecall_notify() Found call with id: 1 Feb 09 21:22:12 VollaPhone22 ofonod[3393]: ofonod[3393]: src/handsfree-audio.c:agent_disconnect() Agent :1.187 disconnected Feb 09 21:22:12 VollaPhone22 ofonod[3393]: src/handsfree-audio.c:agent_disconnect() Agent :1.187 disconnected Feb 09 21:22:13 VollaPhone22 ofonod[3393]: ofonod[3393]: src/handsfree-audio.c:am_agent_register() Agent :1.224 registered with the CODECs: CVSD Feb 09 21:22:13 VollaPhone22 ofonod[3393]: ofonod[3393]: src/handsfree-audio.c:am_agent_register() Wideband speech disabled: no mSBC support Feb 09 21:22:13 VollaPhone22 ofonod[3393]: src/handsfree-audio.c:am_agent_register() Agent :1.224 registered with the CODECs: CVSD Feb 09 21:22:13 VollaPhone22 ofonod[3393]: src/handsfree-audio.c:am_agent_register() Wideband speech disabled: no mSBC support Feb 09 21:22:22 VollaPhone22 ofonod[3393]: ofonod[3393]: src/binder_voicecall.c:binder_voicecall_hangup() slot1 hanging up call with id 1 Feb 09 21:22:22 VollaPhone22 ofonod[3393]: src/binder_voicecall.c:binder_voicecall_hangup() slot1 hanging up call with id 1 Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 73 70 6f 6e 73 65 00 00 85 2a 74 70 ioRespon se...*tp Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0030: 00 00 00 00 60 20 14 9a 7f 00 00 00 0c 00 00 00 ....` .. ........ Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0050: 00 00 00 00 .... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: slot1 < [000000a3] 10 getCurrentCalls Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0020: 69 6f 00 00 a3 00 00 00 io...... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: slot1 > 2 callStateChanged Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0020: 69 6f 49 6e 64 69 63 61 74 69 6f 6e 00 00 00 00 ioIndica tion.... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0030: 01 00 00 00 .... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: slot1 < 130 responseAcknowledgement Feb 09 21:22:22 VollaPhone22 ofonod[3393]: slot1 > 2 callStateChanged Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0020: 69 6f 49 6e 64 69 63 61 74 69 6f 6e 00 00 00 00 ioIndica tion.... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0030: 01 00 00 00 .... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: slot1 < 130 responseAcknowledgement Feb 09 21:22:22 VollaPhone22 ofonod[3393]: slot1 > [000000a3] 140 getCurrentCallsResponse_1_2 Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 32 3a 3a 49 52 61 64 .radio@1 .2::IRad Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0020: 69 6f 52 65 73 70 6f 6e 73 65 00 00 85 2a 74 70 ioRespon se...*tp Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0030: 00 00 00 00 48 21 14 9a 7f 00 00 00 0c 00 00 00 ....H!.. ........ Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0050: 00 00 00 00 85 2a 74 70 00 00 00 00 58 21 14 9a .....*tp ....X!.. Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0060: 7f 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0070: 00 00 00 00 00 00 00 00 00 00 00 00 85 2a 74 70 ........ .....*tp Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0080: 01 00 00 00 68 21 14 9a 7f 00 00 00 60 00 00 00 ....h!.. ....`... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0090: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 00A0: 00 00 00 00 85 2a 74 70 01 00 00 00 c8 21 14 9a .....*tp .....!.. Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 00B0: 7f 00 00 00 0e 00 00 00 00 00 00 00 02 00 00 00 ........ ........ Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 00C0: 00 00 00 00 18 00 00 00 00 00 00 00 85 2a 74 70 ........ .....*tp Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 00D0: 01 00 00 00 d8 21 14 9a 7f 00 00 00 01 00 00 00 .....!.. ........ Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 00E0: 00 00 00 00 02 00 00 00 00 00 00 00 30 00 00 00 ........ ....0... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 00F0: 00 00 00 00 85 2a 74 70 01 00 00 00 00 00 00 00 .....*tp ........ Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0100: 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 ........ ........ Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0110: 00 00 00 00 48 00 00 00 00 00 00 00 ....H... .... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: slot1 < [000000a4] 13 hangup Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0020: 69 6f 00 00 a4 00 00 00 01 00 00 00 io...... .... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: slot1 > [000000a4] 12 hangupResponse Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0020: 69 6f 52 65 73 70 6f 6e 73 65 00 00 85 2a 74 70 ioRespon se...*tp Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0030: 00 00 00 00 60 20 14 9a 7f 00 00 00 0c 00 00 00 ....` .. ........ Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0050: 00 00 00 00 .... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: slot1 < [000000a5] 10 getCurrentCalls Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0020: 69 6f 00 00 a5 00 00 00 io...... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: slot1 > 2 callStateChanged Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0000: 61 6e 64 72 6f 69 64 2e 68 61 72 64 77 61 72 65 android. hardware Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0010: 2e 72 61 64 69 6f 40 31 2e 30 3a 3a 49 52 61 64 .radio@1 .0::IRad Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0020: 69 6f 49 6e 64 69 63 61 74 69 6f 6e 00 00 00 00 ioIndica tion.... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: 0030: 01 00 00 00 .... Feb 09 21:22:22 VollaPhone22 ofonod[3393]: src/voicecall.c:ofono_voicecall_disconnected() Got disconnection event for id: 1, reason: 1 Feb 09 21:22:22 VollaPhone22 ofonod[3393]: slot1 < 130 responseAcknowledgement Feb 09 21:22:22 VollaPhone22 ofonod[3393]: sloofonod[3393]: src/voicecall.c:ofono_voicecall_disconnected() Got disconnection event for id: 1, reason: 1 Feb 09 21:22:40 VollaPhone22 ofonod[3393]: ofonod[3393]: plugins/upower.c:battery_props_changed() Feb 09 21:22:40 VollaPhone22 ofonod[3393]: plugins/upower.c:battery_props_changed() ``` ---
**Author:** ![boroli](https://forum.droidian.org/letter_avatar_proxy/v4/letter/b/e36b37/32.png) [@boroli](https://forum.droidian.org/u/boroli)\ **Post date:** [May 7, 2026, 7:29pm UTC](https://forum.droidian.org/t/no-sound-in-voice-calls-after-a-few-days/68/8 "2026-05-07T19:29:12Z")
I flashed my phone last weekend, made all the updates, and finally could make calls again…until next day. I didn’t change anything. There was no reboot, no freeze, nothing. I literally didn’t touch my phone, and still after ~24 hours of flashing, I can’t make any phone calls again. Is it actually normal that my load average is close to 20 on droidian, even though the CPU usage is close to nothing? ```auto top - 21:22:36 up 4 days, 1:11, 2 users, load average: 19.20, 19.10, 19.06 Tasks: 563 total, 1 running, 562 sleeping, 0 stopped, 0 zombie %Cpu0 : 0.3 us, 3.3 sy, 0.0 ni, 96.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 1.0 us, 0.7 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu2 : 1.3 us, 0.7 sy, 0.0 ni, 97.0 id, 1.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu3 : 1.4 us, 1.0 sy, 0.0 ni, 97.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu4 : 0.0 us, 1.0 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu5 : 0.7 us, 0.3 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu6 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu7 : 0.3 us, 1.0 sy, 0.0 ni, 98.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 3498.4 total, 1019.5 free, 1429.7 used, 1063.0 buff/cache MiB Swap: 1924.1 total, 1685.1 free, 239.0 used. 2068.7 avail Mem ``` ```auto ps aux | awk '$8 ~ /D/ { print $0 }' root 228 0.0 0.0 0 0 ? D May03 0:00 [ccci_poll1] root 270 0.0 0.0 0 0 ? D May03 0:00 [ddp_irq_log_kth] root 272 0.0 0.0 0 0 ? D May03 0:17 [disp_idlemgr] root 273 0.0 0.0 0 0 ? D May03 0:02 [disp_check] root 275 0.0 0.0 0 0 ? D May03 0:00 [decouple_trigge] root 284 0.0 0.0 0 0 ? D May03 0:02 [wdtk-0] root 285 0.0 0.0 0 0 ? D May03 0:02 [wdtk-1] root 286 0.0 0.0 0 0 ? D May03 0:12 [wdtk-2] root 287 0.0 0.0 0 0 ? D May03 0:29 [wdtk-3] root 288 0.0 0.0 0 0 ? D May03 0:09 [wdtk-4] root 289 0.0 0.0 0 0 ? D May03 0:28 [wdtk-5] root 290 0.0 0.0 0 0 ? D May03 0:01 [wdtk-6] root 291 0.0 0.0 0 0 ? D May03 0:01 [wdtk-7] root 300 0.0 0.0 0 0 ? D May03 0:00 [hang_detect] root 331 0.0 0.0 0 0 ? D May03 0:00 [rt9471_bc12_en_] root 333 0.0 0.0 0 0 ? D May03 0:00 [gauge_timer_thr] root 351 0.0 0.0 0 0 ? D May03 0:24 [ipi_cpu_dvfs_rt] root 375 0.0 0.0 0 0 ? D May03 0:00 [qos_recv] ``` ---
**Author:** ![boroli](https://forum.droidian.org/letter_avatar_proxy/v4/letter/b/e36b37/32.png) [@boroli](https://forum.droidian.org/u/boroli)\ **Post date:** [August 28, 2026, 8:42pm UTC](https://forum.droidian.org/t/no-sound-in-voice-calls-after-a-few-days/68/9 "2026-08-28T20:42:23Z")
Voice calls work reliably after a fresh Droidian flash, then suddenly produce no audio on either side (call connects normally, no signaling issue) until the device is reflashed. This last occured directly after a ~2h+ call. Restarting the Android LXC container or the phone does **not** fix it, only a full reflash of `userdata` does. **Confirmed root mechanism** PulseAudio (which loads `audio.primary.mt6768.so` directly via libhybris rather than running a separate Android audio-HAL service) segfaults reliably on entering call mode: ```auto kernel: Core dump to |/usr/lib/systemd/systemd-coredump ... pipe failed systemd[...]: pulseaudio.service: Main process exited, code=killed, status=11/SEGV ``` The crash consistently happens right after: ```auto AudioALSASpeechPhoneCallController: setMuteInfo(), mMuteInfo: 0x0 SpeechParserGen93: appOpsGetInstance(), init AppOps struct, lib is libaudio_param_parser-vnd.so [SIGSEGV] ``` `systemd` auto-restarts `pulseaudio.service` (`Restart=on-failure`), so the service technically stays “up” while the call itself produces only a faint electrical squeal/click and no audio, matching the reported symptom. **Coredump not captured** — `systemd-coredump` fails with `pipe failed`, likely due to sandboxing in the shipped `pulseaudio.service` unit (`NoNewPrivileges`, `RestrictNamespaces`, `SystemCallFilter=@system-service`). No backtrace obtained yet. **Ruled out during investigation** - **VoLTE/AMR-WB/EVS codec** : crash reproduces identically while modem is forced to 2G/3G (`mmcli --set-allowed-modes=2g,3g`), so it is not tied to VoLTE registration or wideband codec negotiation. - **Thread scheduling priority** : every audio thread fails `setpriority(ANDROID_PRIORITY_AUDIO)` with `errno 13/EACCES` in both working and broken states; adding `LimitRTPRIO=95`/`LimitNICE=-20` to the systemd unit had no effect on crash frequency. - **`/data` state divergence** : `diff -rq` between a full `tar` of `/data/vendor` taken right after a working flash and one taken in the broken state showed no meaningful differences (only unrelated camera calibration dump files and an ipsec conf timestamp). - **Runtime PM state of the AFE device** (`/sys/bus/platform/devices/11220000.mt6768-afe-pcm/power/{runtime_status,control}`): inconclusive. Observed `runtime_status: active` (instead of the expected `suspended`) both immediately after a dropped call and, on a separate occasion, persistently after a ~2h call, with no active call in progress. Even after multiple reboots `runtime_status` is always active - and no sound is available in any voice calls anymore. However, forcing a driver rebind (`echo > .../unbind` then `bind`) while the audio stack was live froze the entire device (black screen, unresponsive SSH), requiring a hard reset — this path should **not** be attempted again on a live system; it points at shared clock/power-domain dependencies with other hardware blocks (likely display) that aren’t safe to touch from userspace. **Working-state log reference** (for comparison against future broken-state captures) On a fresh flash, entering call mode logs, in order: ```auto mt6768_afe_runtime_resume() mt6768_afe_enable_clock() mtk_dai_pcm_hw_params(...) mtk_adda_ul_event(), name ADDA Capture Enable ... mtk_stf_event(), name Sidetone Filter ... ``` In the broken state, the AFE resume/clock-enable steps and the ADDA/sidetone setup are consistently **absent** from the log — the flow jumps straight from `hw_params` to device turn-on sequences, suggesting the kernel’s runtime-PM bookkeeping believes the AFE block is already active/clocked when it may not correctly be, though this remains unconfirmed without a kernel-level trace. * * * **Update, additional finding (most significant so far):** `runtime_status` of the AFE platform device persists as `active` indefinitely, confirmed to be a genuinely live/counting state, not a frozen sysfs read: ```auto $ cat .../power/runtime_active_time 2141304 $ sleep 30 $ cat .../power/runtime_active_time 2171320 ``` The delta (30016 ms) exactly matches the elapsed wall time, confirming the kernel’s runtime-PM active-time counter is actively incrementing for this device even with **no audio activity and no call in progress** , and **this persists across a full device reboot** (not just a service/container restart). This rules out a userspace/RAM-only state and points to something the kernel considers a legitimate, un-released active reference on this device, surviving reboot — likely either firmware/co-processor state (e.g. modem/DSP side) or a persistent driver-internal flag, not plain kernel memory. No `runtime_usage` or debugfs `pm_genpd` interfaces are available on this kernel build to inspect the raw refcount directly. * * * **Some ideas to go further - other thoughts?** - A working coredump (fix the sandboxing/coredump pipe issue in `pulseaudio.service`, or run PulseAudio outside the restricted unit temporarily) to get an actual backtrace out of `SpeechParserGen93`/the vendor audio-HAL. - Ideally, someone with access to the MediaTek `mt6768-audio` kernel driver source and the vendor `audio.primary.mt6768.so` HAL source, since further blind experimentation on the live device carries real risk of hanging shared hardware blocks (as demonstrated above). ---
**Author:** ![boroli](https://forum.droidian.org/letter_avatar_proxy/v4/letter/b/e36b37/32.png) [@boroli](https://forum.droidian.org/u/boroli)\ **Post date:** [October 31, 2026, 1:11pm UTC](https://forum.droidian.org/t/no-sound-in-voice-calls-after-a-few-days/68/10 "2026-10-31T13:11:19Z")
**Update: crash analysis, a working workaround (no reflash) and everything I ruled out** Short version: on my Vollaphone 22 the PulseAudio crash at the start of a call is a **deterministic out-of-bounds write inside the Android audio HAL** , caused by an invalid shared-memory header. Resetting the mixer control `Speech_SHM_Init` (plus five stuck switches) and restarting PulseAudio brought calls back **without reflashing**. I do not yet fully understand _why_ the broken state survives reboots, so please read the workaround as “works on one device, not yet stress-tested”. ## TL;DR - **Symptom:** the call connects, then there is no audio on either side. PulseAudio segfaults right after `PCM_2_EN event 0x1` (call setup), restarts, and segfaults again. - **Crash site:** `android::sph_memcpy()` in `audio.primary.mt6768.so`, called from `SpeechExtMemCCCI::shm_region_write_from_linear()`. It writes to `base + 0xfffffdff` instead of somewhere inside a 0xd000 byte shared-memory mapping (`/dev/ccci_raw_audio`). - **Why:** the region descriptor in that shared memory contains `offset = 0xfffffdff`, `size = 0xffffffff` instead of `0x80` / `0x3000`. The HAL only checks for `size == 0`, so it happily writes into nowhere. - **Workaround that worked:** set `Speech_SHM_Init` and the five stuck switches to 0 and restart PulseAudio. A small systemd unit now does the `Speech_SHM_Init` part at every boot. - **Not known yet:** what exactly triggers the recovery (see “Open questions”), and whether the unit survives a hard reset. ## Setup - Vollaphone 22 (MediaTek MT6768), kernel `4.19.191-volla-mimameid-h12`, Droidian phosh image (api32) flashed with `flash_all.sh` on 1 September - PulseAudio loads `/android/vendor/lib64/hw/audio.primary.mt6768.so` directly via libhybris, Android runs in `lxc@android`, `callaudiod` requests the call profile - Modem set to 2G/3G (VoLTE doesn’t run yet; this turned out to be irrelevant for the crash) - The same phone and SIM make calls on Ubuntu Touch without problems - The only fix I had until now was a full reflash ## Timeline - 1 Sept: fresh flash, calls worked for about six weeks (several successful calls on 17 Oct) - 19 Oct: black screen (suspected out-of-memory), forced reset with the power button held for 15 s. **The first call after that was silent, and every call since then.** - Earlier episodes (for example 28 Aug: 2 h call, display flapping, hwcomposer restart loop, watchdog reboot, afterwards silent calls) fit the same pattern. My suspicion is that the trigger is an **unclean reboot** , not elapsed time. I only have timestamps proving this for the 19 Oct case. ## What the logs show At call setup the kernel log shows this sequence, every time: ```auto mt6768-audio 11220000.mt6768-afe-pcm: mt6768_afe_runtime_resume() mt6768-audio 11220000.mt6768-afe-pcm: mtk_pcm_en_event(), name PCM_2_EN, event 0x1 kernel: [pid:pulseaudio] Core dump to |/usr/lib/systemd/systemd-coredump ... 11 ... pipe failed callaudiod: Error in PulseAudio context: Connection terminated mt6768-audio ...: mtk_pcm_en_event(), name PCM_2_EN, event 0x8 ``` Signal 11 is a segfault. The crash happens at call setup, not when the other side picks up. Coredumps cannot be written on this kernel (`CONFIG_STATIC_USERMODEHELPER_PATH=/system_ext/bin/aee_core_forwarder`, hence “pipe failed”), and there is no kernel source or debugfs, so I used gdb and the HAL binary directly. **Side effect of the crash, not the cause:** `/sys/bus/platform/devices/11220000.mt6768-afe-pcm/power/runtime_status` stays `active`. Five mixer switches are left on (`PCM_2_PB_CH1 ADDA_UL_CH1`, `PCM_2_PB_CH2 ADDA_UL_CH2`, `ADDA_DL_CH1 PCM_2_CAP_CH1`, `ADDA_DL_CH2 PCM_2_CAP_CH1`, `Sidetone Filter Switch`) and are saved in `/var/lib/alsa/asound.state`, so the status survives reboots, poweroff and battery removal. Switching them off gives `suspended` again, but the next call crashes again and puts everything back. A reproduction started from `suspended` and clean mixer routes still crashed, so this state is not a precondition. ## Getting a usable crash site > **gdb procedure and how I mapped addresses** > > ```auto > systemctl --user stop pulseaudio.service pulseaudio.socket > XDG_RUNTIME_DIR=/run/user/$(id -u) gdb --args /usr/bin/pulseaudio --daemonize=no --log-target=stderr > (gdb) run > # start a call, wait for SIGSEGV > (gdb) info registers > (gdb) info proc mappings > > ``` > > `bt` is useless (no CFI in the vendor libraries), but `pc` lies inside the executable mapping of `audio.primary.mt6768.so`. For this library the symbol addresses printed by `nm -D --defined-only` are identical to file offsets, so: > > ```auto > file offset = pc - (start of r-xp mapping) + (file offset of that mapping) > > ``` > > Libraries move between runs (hybris loader), but `$pc` expressions work in a live session, for example `x/215i $pc-0x131a08+0xf9f58` for the function that contains the crash call. Installing `binutils` allows `objdump -d --start-address=... --stop-address=...` directly on the `.so`, no crash needed. Result, identical in two independent runs on different boots: - Faulting instruction: `strb w9, [x0], #1` - Function (exported symbol at file offset 0x1319f8, crash is 0x10 bytes in): `android::sph_memcpy(void*, void const*, unsigned int)`, a byte copy loop - `x0` (destination) = `0x80f7f72dff`, not mapped - `x0 = x24 + x25`, where `x24` is the **start of the mapping `/dev/ccci_raw_audio` (0xd000 bytes, rw-s)** and `x25 = 0xfffffdff` - `x19 = 0xcd0` (length 3280), `x23 = 0xffffffff`; only the ASLR-dependent addresses differ between runs ## Why the destination is wrong The caller is `android::SpeechExtMemCCCI::shm_region_write_from_linear(region_info_t*, void const*, unsigned int)`. From the disassembly (field names are my interpretation): - `region_info` is a 16-byte struct in the shared memory: `{offset, size, read_idx, write_idx}`; for the failing region it sits at `base + 0x28` - the destination is `base + offset + write_idx` - the only validation is `size != 0` and `idx < size` From the registers, the failing descriptor held `{0xfffffdff, 0xffffffff, 0, 0}`. That passes both checks and gives the wild pointer. I could not read the memory directly, because gdb answers “Cannot access memory” for this device mapping (probably because ptrace cannot read it). The correct header is written by `SpeechExtMemCCCI::formatShareMemory()`: > **What formatShareMemory() writes (from objdump)** > > - checks that the mapping exists and is larger than 0xcfff bytes (mine is 0xd000) > - calls `get_uint32_from_mixctrl("vendor.audiohal.speech.shm_init")` > - **if the value is 0:** formats the header, zeroes the data areas, then calls `set_uint32_to_mixctrl("vendor.audiohal.speech.shm_init", 1)` > - **if the value is not 0:** skips formatting entirely and only logs the existing header values > > Layout it writes: > > | Part | Offset in mapping | Size / content | > | --- | --- | --- | > | guard pattern | 0x00 | 32 bytes of 0x0a | > | flags | 0x20 | bit 0 set after formatting | > | region 0 descriptor | 0x28 | `{0x80, 0x3000, 0, 0}` | > | region 1 descriptor | 0x38 | `{0x3080, 0x2000, 0, 0}` | > | region 2 descriptor | 0x48 | `{0x5080, 0x7f60, 0, 0}` | > | tail guard | 0xcfe0 | 32 bytes of 0x0a | The name `vendor.audiohal.speech.shm_init` matches the ALSA control `Speech_SHM_Init` (there are also `Speech_SHM_USIP` and `Speech_SHM_Widx`). I did not verify the name mapping in the code, but the behaviour fits: `Speech_SHM_Init` is a boolean mixer control, it is saved in `asound.state` (`value true` in mine), and it is on during calls. I also confirmed that **PulseAudio itself sets it back to 1 at start-up** : stop PulseAudio, `cset Speech_SHM_Init 0`, `cget` shows `off`, start PulseAudio, after 8 s `cget` shows `on`. ## The workaround What I ran with PulseAudio running: ```auto for c in 'PCM_2_PB_CH1 ADDA_UL_CH1' 'PCM_2_PB_CH2 ADDA_UL_CH2' \ 'ADDA_DL_CH1 PCM_2_CAP_CH1' 'ADDA_DL_CH2 PCM_2_CAP_CH1' \ 'Sidetone Filter Switch' 'Speech_SHM_Init'; do sudo amixer -c 0 cset name="$c" 0 >/dev/null done ``` Result: the next call still crashed the old PulseAudio instance, the restarted instance did not crash, audio worked, and after hanging up `runtime_status` went back to `suspended` for the first time since hart reset. The cleaner variant is to stop PulseAudio first and start it again afterwards. To make this happen at every boot **before** PulseAudio starts, I added this unit (my UID is 32011, check yours with `id -u`; the wait loop is there because the control may not exist yet): ```auto # /etc/systemd/system/speech-shm-reset.service [Unit] Description=Reset Speech_SHM_Init so the audio HAL reformats the shared memory After=sound.target alsa-restore.service Before=user@32011.service [Service] Type=oneshot ExecStartPre=/bin/sh -c 'for i in $(seq 1 20); do /usr/bin/amixer -c 0 cget name=Speech_SHM_Init >/dev/null 2>&1 && exit 0; sleep 1; done; exit 0' ExecStart=/usr/bin/amixer -c 0 cset name=Speech_SHM_Init 0 [Install] WantedBy=multi-user.target ``` ```auto sudo systemctl daemon-reload sudo systemctl enable speech-shm-reset.service ``` After a normal reboot the unit ran right after `alsa-restore` (`alsa-restore.service` took about 96 s on that boot, cause unknown), and the first call worked without a crash. A healthy system survives normal reboots anyway, so this only proves that the unit does no harm. **The real test is a hard reset, which I have not done yet.** ## Related problem: the black screen that forces the hard resets (and the earlyoom mitigation) My working theory is that the broken audio state is triggered by an **unclean reboot**. The unclean reboot was a forced reset after a black screen, so keeping the display stack alive is the first line of defence. The `Speech_SHM_Init` unit above is the second one. ### What I saw - The screen went black right after opening Firefox (I was away from home, so no SSH). The same morning it had already gone black once, and SSH still worked then. RAM and swap were full, and hanging Firefox processes had to be killed afterwards. The journal shows `phosh` segfaulting at 15:50:03, **two seconds after Firefox had opened and closed the V4L2 hardware video encoder and decoder** (`17000000.vcodec_enc`, `16000000.vcodec_dec`), followed at 15:50:10 by `phosh.service: Scheduled restart job` and the start of `android-service@hwcomposer.service`. - That last line is less alarming than it looks: `android-service@hwcomposer.service` has `BindsTo=phosh.service` and `Before=phosh.service`. The “hwcomposer crash loop” I first suspected is really **phosh restarting**. - **Another incident after a long call:** `phoc` aborted with SIGABRT, `phosh` logged “Error reading events from display: Connection reset by peer” and died, and the whole session restarted. The proximity sensor was already disabled at that time, so it is not the cause (`gsettings set mobi.phosh.shell.proximity enable-proximity-sensor false`). - Second incident: The OOM killer fired (triggered by `kgx`). The Mali driver’s OOM notifier listed `dev mali0 1287932 kB` in total, of which **`loupe` (image viewer) held 1143684 kB of GPU memory**. - During a 2 h call, the display flapped about 130 suspend/resume cycles per minute, followed by a hwcomposer loop and a watchdog reboot. My interpretation (a guess): GPU memory held by a single app can exhaust the system without being visible in the usual tools. Then the kernel OOM killer or a crashing compositor takes the session down, and in the worst case the phone becomes unresponsive and needs the 15 s power-button reset. ### What I changed - avoiding `loupe` and Firefox for large images and video - Firefox: `media.hardware-video-decoding.enabled` set to `false` in `about:config` (the V4L2 path had been opened right before the phosh crash) - `earlyoom` with `--prefer` for the likely culprits ### earlyoom setup ```auto sudo apt install earlyoom sudoedit /etc/default/earlyoom ``` ```auto # /etc/default/earlyoom EARLYOOM_ARGS="-m 8 -s 30 --prefer '(loupe|Web Content|Isolated Web Co|firefox)' --avoid '(phosh|phoc|gnome-shell|systemd)'" ``` ```auto sudo systemctl restart earlyoom systemctl status earlyoom --no-pager journalctl -u earlyoom -b --no-pager | tail ``` Notes: - `--prefer` and `--avoid` are regular expressions matched against the process name. They matter here because earlyoom chooses its victim by the kernel’s badness score, which is based on RSS and does not include GPU memory. Without `--prefer` it would probably kill an innocent process while the real hog keeps its gigabyte of GPU memory (my reasoning, not verified). - I could not verify whether GPU allocations lower `MemAvailable` early enough for earlyoom to react. A fast leak may still beat it. - After an OOM event, `journalctl -k | grep -i -B2 -A8 'OOM notifier'` shows the per-process GPU numbers from the Mali driver. ### Status If anyone knows how to read per-process Mali memory on a live system without debugfs, or has seen `loupe`, Firefox or other apps balloon GPU memory on this device, please say so. ## What I ruled out None of these changed the crash: - Thread priority (`setpriority errno 13` appears in working and broken states alike) - Contents of `/data/vendor` and the PulseAudio `.tdb` files (`stream-volumes.tdb` moved away) - Deleting the NVRAM files `NA87_000` and `ER1D_002`, and later **all 140 files in `/mnt/vendor/nvdata/md/NVRAM/NVD_DATA/`** (the modem regenerates them with the same sizes, the crash stays) - Reboot, poweroff, battery removal - Memory or disk exhaustion - Package updates: `dpkg.log` and `apt/history.log` show no installs between the last working call and the first failure - Masking `alsa-restore.service` and `alsa-state.service`, moving `asound.state` away and rebooting (see open questions, this does not fit my model) - Modem side: `/sys/kernel/ccci/boot`, `version` and `mdsys1/parameter` are identical to a capture from a fresh flash, and the kernel `ccci` messages are identical across boots - Filesystem damage after the forced reset: ext4 replayed the journal (2 orphan inodes), nothing audio-related was empty or changed - An Android tombstone of `vendor.mediatek.hardware.mtkpower@1.0-service` after the reset (heap corruption abort one second after process start). It came after the first audio failure, so it is not the trigger. - The install zip contains no modem data (only `boot`, `dtbo`, `vbmeta`, `recovery`, `userdata` and the script) - Careful with: unbind/bind of the AFE driver, `echo mem > /sys/power/state` and writes to `/sys/kernel/ccci/md_en` all hang the phone (15 s power button needed). I stayed away from the `persist`, `nvdata` and `nvram` partitions, and raw `nvram`/`nvdata` images contain IMEI and calibration data. ## Open questions 1. **Why does the broken state survive reboots, and why did my earlier `asound.state` test not help?** My working model: the flag lives in the mixer state and is restored at boot, while the shared-memory header lives in RAM and is lost after a hard reset, so the HAL believes it is already formatted. That would explain “only a reflash helps” (there is no `asound.state` after a flash). But a boot with `alsa-restore` masked and `asound.state` moved away should then have worked, and it did not. Maybe the kernel default of the control is 1, but I have not checked. 2. **Does writing the control itself trigger something in the kernel (or on the audio coprocessor)?** My boot logs contain `[SCP] scp_send_obj` lines. A check of the kernel log around the write was inconclusive because WLAN messages drowned everything. 3. Does the unit prevent the failure after a hard reset? If it still breaks despite the unit, the most useful data would be `journalctl -b -u speech-shm-reset.service`, then trying separately: only restarting PulseAudio, only `cset Speech_SHM_Init 0` with PulseAudio running, and stopping PulseAudio, `cset 0`, starting it again. 4. The last run for six weeks before the forced reset. ## How to check whether you have the same problem ```auto journalctl -k | grep -E 'PCM_2_EN|Core dump' # core dump right after event 0x1? amixer -c 0 cget name='Speech_SHM_Init' # on/off amixer -c 0 contents | grep -B2 ': values=on' | grep -o "name='[^']*'" cat /sys/bus/platform/devices/11220000.mt6768-afe-pcm/power/runtime_status grep -A8 Speech_SHM_Init /var/lib/alsa/asound.state ``` If you can run the gdb procedure above, compare `x23` and `x25` at the crash (`0xffffffff` and `0xfffffdff` for me) and the faulting instruction. ## For the maintainers - The HAL’s only plausibility check for the region descriptor is `size == 0`, so a stale descriptor leads to a crash instead of an error message. - Whether the adaptation or the image should reset `Speech_SHM_Init` at boot is probably worth a look. As far as I can tell, a missing `asound.state` (fresh flash) leads to a clean format, a restored `true` skips it. - A related but separate problem on my device is the black-screen and phosh-restart issue after long calls (Mali memory, `loupe`, Firefox V4L2), which is what forces the hard resets in the first place. I am happy to post more raw output, the disassembly of `formatShareMemory` or the exact commands for any step. If anyone has seen a non-reflash recovery or knows what the `Speech_SHM_Init` write does in the kernel driver, I would love to hear it.