It’s a bit inconsistent, too… I have used GPS every now and then for 10-15 minutes for testing this, and so far I haven’t been able to reproduce it with short sessions…
It may also have something to do with OOM killer, because I have only been able to reproduce it with Here WeGo navigator, which eats up quite a lot of RAM. It’s not a trivial task to hunt this down…
I’m having this issue again. I could collect some logs, what would be useful? I can survive this for a few days at least 
PS. I did use GPS for 1.5h two days ago, this could be because of that, not sure, but certainly possible.
Perhaps collect all log since device has booted and then filter.
I have seen this a couple of times now too. Seems to happen even during inactivity, or maybe at the end of usage.
After using the GPS, which i barely do, i always restart the phone. The bug didn’t occur for weeks now, so i think it is definetly GPS related.
Did any of you check miau’s solution? [Xperia 10 III] Audio suddenly completly gone - #7 by miau
It did fix this issue for me, unless I have been extremely lucky so far.
Not yet, but I have GPSinfo running, and pulseaudio and ngfd restart scripts ready
When I hit the bug, I’ll test them one after other to what fixes it for me. I think the pulseaudio conf change comes last for me, I’ll try to find the general direction first.
I just hit the bug this morning, after 6d of uptime and no GPS use. I believe it was an OOM kill, necause I was at 5.0/5.38GB according to htop. Running the pulseaudio commands above solved it without reboot (at least for playing audio).
I haven’t tried the pulseaudio config change, but I doubt it would have affected the OOM kill in this case.
Just another little data point: Bluetooth headset plays music just fine with native and Android apps.
I can confirm this behaviour. My alarm stopped working yet again, so I’ve taken a moment to test this. With a music player trying to play a song (but frozen because of this bug), as soon as the bluetooth speaker connects playback starts working. Disconnect playback, it’s frozen again. This can be repeated over and over.
I also want to take this moment to reiterate how critical this bug is. Not being able to hear your alarm in the morning or incoming phone calls is unacceptable, working audio is a critical functionality on a mobile phone. Can we please get a confirmation by Jolla that this bug will finally be fixed in the next update?
The very same problem (no alarm, or incoming call ringtone, or SMS sound, etc.) can be caused by the ambience switching bug, too. But I was already scolded for talking about it too often (i.e. twice) rather than letting it grow old.
I have a realy good feeling that the issue occur when the phone has been contacted to a certain kind of sound Bluetooth and the connection has been cut.
I will test this further.
My report from yesterday happened on a clean boot with no bluetooth connections made or bluetooth even enabled. I had rebooted my phone in the afternoon on Friday, then the alarm failed to go off Saturday morning.
Today this happened yet again, again causing me to almost miss an appointment. It just so happens that today is also a Saturday 
What happened is that I had set an extra alarm half an hour before my regular alarm to make sure I had some extra time available. Then in the morning the alarm went off, but there was no sound (only the vibration). Half asleep I thought that this was my ‘extra time’ alarm and I had just forgotten to enable sound and so I snoozed it.
What had actually happened, I found out, is that somehow the first alarm had failed altogether (there is no way to control ring/vibration), and I was snoozing my regular alarm (which was already set ‘too late’).
I don’t know how the first alarm failed, but I don’t believe I slept through its vibrations, as a new alarm appears to be created in ‘enabled’ state, so I’m pretty sure it was active when I went to sleep.
Sadly, the sudden lack of audio happened to me already twice on the 10 III (the second time yesterday). Shortly speaking, out of nowhere the device stops producing ANY sounds. At the same time, volume control buttons stop reacting too (pressing them has no effect, there are no volume level bars shown, etc).
This is a very serious issue (I missed an important call because of that since there was no ringtone) and I really hope it’ll be considered urgent and taken care of.
EDIT: Video freezing (causing that the entire application playing the video - e.g. Gallery - stops responding) happens regularly, too. Quite annoying, but not as serious as sudden disappearance of audio which happens unnoticed and leads to missed calls, alarms, messages, etc.
Confirm! Happens time to time ( when disconnect bt car audio for example, no 100% in that case, but sometimes)
Command below helps in most cases
systemctl --user restart pulseaudio
I am still super curious why systemd doesn’t restart it automatically.
But as far as I know pulseaudio gets killed by the OOM killer. And if you tweak it as described here, problem gets less frequent.
But to actually fix the problem, the systemd service would have to be tweaked somehow, so it detects pulseaudio problem and restarts it (it is already set to always restart, but for some reason it doesn’t work), pulseaudio would have to get excluded from the OOM Killer, which I don’t think is possible, or we would have to wait for a new OOM Killer daemon, which can choose which app to kill, which will probably take a ton of time.
Perhaps a watchdog could do the trick? Now, what’s the actual condition we can check?
Those are the contents of /usr/lib/systemd/user/pulseaudio.service contains the following.
[Service]
EnvironmentFile=-/etc/sysconfig/pulseaudio
# Wait until system PulseAudio daemon has completely shut down before
# starting user session daemon.
ExecStartPre=/bin/sh -c "while [ -f /run/pulse/pid ]; do sleep 1; done"
ExecStart=/usr/bin/pulseaudio --daemonize=no $CONFIG
Restart=always
RestartSec=1
Type=notify
Restart=always means it will will restart it not just on error, but but if the process stops in any way. At least I think that is what it should do if the service was enabled. But for me, it was disabled for some reason.
systemctl --user status pulseaudio.service
● pulseaudio.service - PulseAudio
Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; vendor preset: enabled)
So now I did systemctl --user enable pulseaudio.service we will see if my device explodes, or maybe it will fix it?
Otherwise it this doesn’t work, I would look into Type=notify and systemd messaging and try to catch if when pulseaudio stops working, if it creates any message.
In June I reported that the bug occurred to me after using PureMaps/GPS (see the earlier posts in this thread). When using PureMaps for navigation, I connect the phone to car audio via Bluetooth. Accordingly, the bug may well be Bluetooth-related according to my experience. But: the bug did not occur when I used the car’s Bluetooth connection for hands-free calls. I don’t no whether this gives any clue or not - just to let you know