Editor uses CPU time in the background due to the audio server being kept active

[davidhudson]

Godot version

3.4 Stable

System information

Windows 11 / Surface Pro 8 / i7 x86_64

Issue description

Having the editor open but minimised / unfocused eats up 1-2 hours of battery life. Cause seems to be continuous use of Windows Audio Device Graph Isolation. Desktop Window Manager usage is also much higher than when the editor is closed.

This can also be seen by running powercfg /requests in the terminal.

SYSTEM:
[DRIVER] Realtek High Definition Audio(SST) (INTELAUDIO\FUNC_01&VEN_10EC&DEV_0274&SUBSYS_10EC122E&REV_1000\5&1543d6b8&0&0001)
An audio stream is currently in use.

Sometimes, but not consistently this also prevents sleep when closing the keyboard cover.

Might be analogous to these issues affecting MacOS:
#28039
#38154

Maybe this is a minor issue in the grand scheme of things, but usability is impacted when you have to keep opening and closing a project when you don't expect to work on it for even a hour less you sacrifice some battery!

Steps to reproduce

Open the editor

Minimal reproduction project

No response

[Calinou]

As a workaround, start the editor with the --audio-driver Dummy command line argument. This will prevent audio playback from working in the editor, but it should still work in the running project as it's a separate process.

See also #38208, which fixes this issue in the project manager (but not the editor).

Until something like #45948 is implemented on all platforms, we could add an editor setting to use the Dummy audio driver when editing any project. This way, you don't have to always specify the command line argument anymore.

[wb14123]

Start the editor with --audio-driver Dummy doesn't work for me. pulseaudio is still using the same amount of CPU. In KDE, I can see there is speech-dispatcher-dummy playing audio now.

[lawnjelly]

Start the editor with --audio-driver Dummy doesn't work for me. pulseaudio is still using the same amount of CPU. In KDE, I can see there is speech-dispatcher-dummy playing audio now.

This is in 3.x or 4.x or both?

This sounds like a new problem related to text to speech creating an audio output. 🤔
Pinging @bruvzg as this is his area - It might be totally normal for text to speech.

[wb14123]

@lawnjelly This is only in 4.x branch. When I try 3.x with --audio-driver Dummy, there is no application showing playing sound in KDE.

[bruvzg]

speech-dispatcher is a completely independent process, so we can't directly control what it is doing.

I guess we can postpone speech-dispatcher init until it is used, but since starting it take some time, it will make first TTS call slow, so I'm not sure about it.

Is it causing significant CPU usage, or just listed in the audio mixer?

[lawnjelly]

@bruvzg Just to confirm, is there a project setting for text to speech? It should presumably be off by default unless required in the project.

[wb14123]

@bruvzg It is causing significant CPU usage for pulseaudio when using --audio-driver Dummy

[bruvzg]

Just to confirm, is there a project setting for text to speech? It should presumably be off by default unless required in the project.

No, there's no option to disable it completely. But if it's causing issues, we probably should add one.

when using --audio-driver Dummy

TTS is not affected by audio-driver option, since sound is generated by the speech-dispatcher (or other system component depending on OS) not by Godot.

[lawnjelly]

This regression (I'm presuming the text to speech) also appears to be happening in 3.x, I'm getting up to 11 percent CPU used by pulse audio with Godot audio switched off. I'll have a look at fixing this asap, as this is a big problem for low power computers.

EDIT: I've added a separate issue for the TTS (#77124) .. it has a different cause so does deserve it's own issue.