.

[rancidfrog]

.

[kholk]

This should happen because of a vidc/iommu bug reproducible by opening and closing multiple vidc hardware enc/decoder instances while c2d composition (hardware assisted rendering) is enabled.

After small tests, I couldn't reproduce the issue on the new 1.3.3 branch.
The new 1.3.3 branch will be considered as main/stable very soon! Please, test the still bleeding edge 1.3.3 branch to confirm that the bug is gone.

Thanks!

[kholk]

The in call volume bug is not kernel related!

[mcgi5sr2]

@kholk could you share some info on what is causing the in call volume issue?

[kholk]

It looks like android tries to manage the wrong mixer for the in call volume function. That's all I know and it's only my supposition.

[jerpelea]

voip apps use different audio paths

[kholk]

This looks really like a buffer size mismatch for the encoded chunk of data sent to the Venus block.
Reiterating in more understandable words, it looks like the system sends too much data to Venus HW, more than it can handle (or improperly aligned).

[kholk]

It looks like your device started the suspend sequence while you were in call.
This should not happen.... While in call your device should stay awake, so something is not setting the wakelock.

[mcgi5sr2]

@rancidfrog frog have you tried using GApps for calling, this would tell you if it was an apk issue...
You could also test some of Davids commits for audio
https://github.com/SonyAosp/device_sony_shinano/commit/f4dde790b1b64d947086909da6b7e482561ed1b2
https://github.com/SonyAosp/device_sony_shinano/commit/5bb1fbc19c39ac54e63fbcd98aa830004c06ff51
and a bunch of stuff on qcom Audio
https://github.com/SonyAosp/platform_hardware_qcom_audio/commits/android-7.0