A service runs for about an hour with nobody obliged to touch the computer. Nothing about a live translation looks like activity to the operating system: audio arrives over USB into a background process, the mouse has not moved since the sermon started, and the screen may well be locked. Windows and macOS both count that as idle, and both are entitled to sleep.
This page is how you stop that happening, and how you check.
What the app does on its own
While a service is live, Yazyk asks the machine not to sleep, and withdraws the request the moment capture stops.
| Asked from | the moment capture actually starts, and held for the whole run |
| Withdrawn on | Stop, an engine crash, and quitting the app |
| Windows | a system-required power request |
| macOS | a no-idle-sleep assertion |
It is not a display hold. The screen may still blank on its own timer, and the operator may still lock the machine. Neither stops capture, because a locked session keeps running on both platforms. Holding a screen lit for ninety minutes in a dark room is an imposition nobody asked for.
The app cannot tell you whether the machine agreed. This is the important limit on this page. The request is filed and the call returns; the wake lock is taken asynchronously and no result ever comes back, so nothing in the app can tell a granted request from a refused one. The log line says only what was attempted:
> asked this machine to stay awake until StopTreat that as a record of the attempt, not as proof. The last section on this page is the proof, and it is the only proof there is. If the request could not even be made, the app says so instead, which is a rarer and more obvious failure:
> could not ask this machine to stay awake - the run continues, but check its sleep settingsEither way the run continues. A power request that cannot be had is never the reason a service does not run.
What you still have to set
The app covers automatic idle sleep. It cannot cover a timer the operating system treats as user policy, and it cannot cover anything a person does deliberately. Set these once per machine, on the account the volunteer actually signs in to.
Windows
Apply the Plugged in column, and keep the adapter connected.
| Setting | Where | Set to |
|---|---|---|
| Sleep | Settings, System, Power and battery, screen and sleep timeouts | Never |
| Display timeout | The same page, turn my screen off after | Never, until this machine has passed a rehearsal |
| Screen saver | Settings, Personalization, Lock screen, Screen saver | None |
| Automatic lock | Settings, Accounts, Sign-in options | Dynamic lock off, if your policy permits it |
| Lid action | Power Options, choose what closing the lid does | Do nothing when plugged in, and keep the lid open anyway |
One read-only command tells you how much risk the machine carries:
powercfg /aStandby (S0 Low Power Idle) means Modern Standby, where desktop applications are documented as paused once the system enters standby. On those machines the settings above matter more, not less. Standby (S3) is traditional sleep. Do not try to convert between the two in firmware.
Leave USB selective suspend enabled unless the interface actually drops while the machine is demonstrably awake. Disabling it globally is recommended against, and it is a different failure from one program holding the input exclusively. Only if the audio input disconnects mid-run, and only then, disable it for the plugged-in profile and repeat the full test.
macOS
The macOS path is not yet verified. The stay-awake request is made on both platforms, but it has not been confirmed against a real Mac during a live service, and device selection on macOS is not finished. Treat the Mac as unproven and use Windows for anything that matters.
| Setting | Where | Set to |
|---|---|---|
| System sleep | System Settings, Displays, Advanced | Prevent automatic sleeping on power adapter when the display is off |
| Display off | System Settings, Lock Screen | Never, until proven |
| Screen saver | System Settings, Screen Saver | Start after Never, or leave it. A screen saver alone does not sleep a Mac |
What none of this covers
Be straight about this with whoever runs the desk. No application request survives a deliberate act:
- Closing a laptop lid. On a Mac this sleeps the machine unless it is on power with an external display attached. On Windows it depends on the lid action above.
- Pressing the power button, or choosing Sleep from a menu.
- Losing mains power. Battery rules differ from plugged-in rules on both platforms.
- A managed policy that reimposes a sleep timer on an organization-administered machine.
Run on mains power with the lid open, and keep these settings even though the app asks the machine to stay awake. The request is the belt and the settings are the braces, and since the app cannot confirm its own request, the settings are the half you can actually check.
Proving it took
This is the only real check. The app's log line says what it asked for, not what it got. Only the operating system can answer whether the request is genuinely held, and both platforms will answer while a service is live. Run this at a rehearsal rather than inferring success from the fact that nothing went wrong.
On Windows, in an administrator terminal:
powercfg /requestsYazyk should be listed under SYSTEM. An empty SYSTEM: section while a service is live means the hold is not in place, whatever the log said.
On macOS:
pmset -g assertionsPreventUserIdleSystemSleep should be 1, with Yazyk named in the listing below it.
Both should return to nothing held within a second or two of pressing Stop. A request still held after Stop is a bug: it would leave the machine unable to sleep until the app quits. Please tell us if you see it. Withdrawal is silent in the log for the same reason the hold is only an attempt, in that the app has no way to confirm it and so does not claim it.