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
Are you all sure that gps is affecting this? I have 10mk3 only for few days. Today is the first time it occurs. After a long car drive without using gps. One thing that changed I connected phone to car audio system. Listen to online music, made some calls. Everything worked until the point I disconected phone from car multimedia. I needed my phone wokring so i did rebooted it.
But if it occurs again and in better circumstances I will test it further
At least I am not at all sure that it is GPS related. It might be a mere coincidence because it occurred after using PureMaps - with GPS AND with TTS, i.e. verbal instructions. So it could be related to Bluetooth audio alone.
I only get this bug, when using gps. In the last months it never occured only after using the gps. So, i always reboot after gps use.
The script restart condition doesnāt apply if pulseaudio process doesnāt die but gets messed up inside, i.e. sound stops working. Thatās why I asked (thought out loud) about the actual condition we could check here.
Well, dmesg gets flooded with the error messages already posted, they could give us a hintā¦
Wouldnāt it be possibke to write a script with checks dmesg output for the error message and restarts pulseaudio if the message occurs?
I wrote a script to act on a dbus signal for another issue, if Pulse really sends a singnal there, then all it needs is changing the signal and command executed. It will even work as a user service and not a root one.
But does it send a dbus signal? I never checked.