No sound from session on login screen after sleep. Changed after 1809

I have been using foobar2000 and fooscheduler as an alarm clock for years. When I go to sleep I put computer to sleep and in the morning fooscheduler wakes the computer and starts to play music. I has worked before, but now couple of weeks ago 1809 update was installed on my Windows 10 Pro and I no longer get any sound when the computer wakes up. However I do get sound when I type in my password and login. I also get sound on the login screen when I activate narrator from ease of access tools. I just don't get sound from my open session. I can see that the tracks are playing via foobar's remote interface.

I have Realtek High Definition Audio on the motherboard and have tried different drivers. However I don't believe this is a driver issue. I believe this is a feature that was introduced in 1809 update. Or just a long lived bug that was finally fixed. It kind of makes sense to not have audio playing from the session after sleep.

Does anyone know a way to get the previous behavior back (except uninstalling 1809 update) so I can use my alarm clock again? Any settings? Any registry key?

I believe making the Windows not ask for a password when starting would be workaround, but I don't want to weaken the security of the system.

zabnat said:

I believe making the Windows not ask for a password when starting would be workaround, but I don't want to weaken the security of the system.

Don't bother, it doesn't help. There's still no audio till you interact with the PC somehow.

I'm in exactly the same situation and I've tried a plethora of things already, including, but not limited to:
- Using different audio devices (on-board, USB, HDMI, Bluetooth)
- Disabling logon screen via registry, group policy and a bunch of other methods
- Changing the account type to all possible variations
- Using the built-in Administrator account as the main account
- Disabling fast startup
- Trying every sub-version of 1809 there is (17763.1 - 17763.503)

The only thing that works is indeed reverting back to 1803 or below.

The only somewhat relevant info I've found is this TechNet thread, although it only mentions some arbitrary system update as a solution.

P.S. - The only solution I can think of is scripting an HID driver (such as Unified Remote or AutoHotkey) to simulate user interaction at the exact same time as the Foobar alarm, but that's a pretty messy solution I'd rather avoid having to resort to; may as well set a mechanical alarm to move the mouse at that point.

I seem to have found a solution to the above issue.
I'm not sure it's permanent, nor do I truly understand why it works, but it seems to.

1. run "services.msc"
2. locate "Windows Audio" and double-click it
3. under the "Log On" tab, change to "Local System Account" or any other user, press OK
4. re-start the aforementioned service
5. change the user back to "Local Service", type a password
6. re-start the service again

After doing that, the audio seems to work the same way it did back in 1803 after Foobar wakes the PC up.
Hope this helps anyone else with a similar issue.

I tried changing account for Windows Audio service and it worked. Great find, thanks!

Unfortunately I was a bit exited to try this so I didn't bother to try if any of the Windows updates had magically made the problem go away as I've had Foobar scheduler off 'cause no point of waking up the PC if there is no sound. So can't confirm 100% that it was this that fixed the issue. But now it works and that is the most important part.

I'll monitor my Foobar waking up and playing music for a while and then mark this as solved.

This doesn't seem to be a permanent solution, so I wouldn't rush to marking it as solved.
In my case it seems to stop working after almost any kind of system updates and needs to be re-done again, so it's hardly a solution. Good enough to set every evening before going to bed, but it's merely a workaround.

Yeah, I too noticed that updates will require this to be done again. I made a batch file to make re-applying this workaround easier. Running the sc-command obviously requires admin privileges. Also if any audio is playing while executing, the audio device will need to be reinitialized or a full reboot might be required to get audio back. I was thinking this could be scheduled to run but I have not figured out any trigger where there is no danger of audio being played.

Code:

sc config Audiosrv obj= ".\LocalSystem" password= ""
sc stop Audiosrv
sc start Audiosrv
sc config Audiosrv obj= "NT AUTHORITY\LocalService" password= ""
sc stop Audiosrv
sc start Audiosrv

Another possible workaround is setting the security options of the task that runs the music player to 'Run whether user is logged on or not'. This works everytime, regardless of the audio service, but has the ugly side-effect that the process is spawned non-interactively.

Canuckie said:

P.S. - it's odd that thus far only a few people seem to have have noticed this issue manifesting itself. From my own testing it still exists in 1903, which begs the question - does nobody use music players as alarm clocks anymore? Either that, or we're missing some obvious solution.

I highly doubt that a lot of users are doing this. The vast majority of the userbase is probably using a solution that involves their mobile phone or tablet. In addition, scheduled tasks were always something of a power-user topic since you have to have a basic understanding of what you are doing to make it work.

mmuffins said:

Another possible workaround is setting the security options of the task that runs the music player to 'Run whether user is logged on or not'. This works everytime, regardless of the audio service, but has the ugly side-effect that the process is spawned non-interactively.

I don't think this is an option, since Foobar's alarm doesn't rely on Task Scheduling, but rather Wake Timers: