I spoke to our developer investigating this issue, and he believes it may be a problem caused by the pulsaudio service transitioning from a system service to a user service when the user unlocks their phone (not at the decryption step, but the login step).
However, at this point, it’s not entirely clear that this is the issue, so it would be really helpful if anyone experiencing this could try a few things out.
First, after logging in to your device, running the following two commands (you’ll need developer access) will generate output that shows which of the services are running.
systemctl --system status pulseaudio
systemctl --user status pulseaudio
If things work correctly, the system service should be inactive and the user service should be active. If this isn’t the case, then it could be the source of the problem. If you find your phone in this state, it would be useful to also test out a phone call to establish whether you have audio working or not.
Subsequently, the following commands may get the user service up and running and potentially fix the issue.
devel-su systemctl --system stop pulseaudio
systemctl --user restart pulseaudio
However, note that since this may not be the cause, I can’t guarantee that this will work, but it would be useful to explore it. Basically, any further info you can give from running these various commands and testing out the audio on your phone afterwards, would be very helpful to know at this stage.
I’ve passed on the info about adsprpcd and hopefully that will also be useful.
If it does turn out to be this issue, then unfortunately it’s also likely to be challenging to fix, so I can’t give a timeline on when it might be. Nevertheless, figuring out whether this is the issue will certainly be a useful step in the right direction, so any more info would be appreciated.
