Frosthaven / voicemeeter-windows-volume

Tray app that allows you to sync windows volume and mute state to Voicemeeter volume controls
278 stars 9 forks source link

Voicemeeter crackle when PC auto turn off display. #4

Closed thu2468 closed 2 years ago

thu2468 commented 2 years ago

I have the Apply crackling fix enable. turn off display is set to 10min.

Frosthaven commented 2 years ago

Can you open task manager and tell me what priority audiodg.exe is running at when the crackle returns?

I know crackling is a common audio issue, and the patch we provide may not tackle all causes. Just want to narrow it down and see if it's something we can work around.

thu2468 commented 2 years ago

cpu affinity is set to cpu 1 and priority high

thu2468 commented 2 years ago

also waking up from sleep also does the same thing

thu2468 commented 2 years ago

Maybe a auto restart Voicemeeter when waking up from Sleep/Hibernating/Display turning back on will help

Frosthaven commented 2 years ago

Maybe a auto restart Voicemeeter when waking up from Sleep/Hibernating/Display turning back on will help

If you can confirm that restarting voicemeeter solves this issue, I will keep the ticket open for potential future enhancements in case voicemeeter doesn't patch it themselves.

thu2468 commented 2 years ago

yes restarting Voicemeeter fix the crackling issue

Jerrk commented 2 years ago

i can also confirm that i occasionally have this issue with voicemeeter - long before installing VWV. "restart audio engine" always fixes the issue so it would indeed seem to be an issue endemic to voicemeeter itself.

you could perhaps run a macro that detects when your computer wakes from sleep or when your displays turn on. though i'm not sure what program would do that for you, maybe displayfusion (i know it has a trigger for "system wakes from sleep" and "desktop unlocked").

Frosthaven commented 2 years ago

That definitely sounds doable. A sort of extension to voicemeeter's automatic engine restarts.

The road to there seems to be:

Sounds like we have a roadmap for this enhancement!

Frosthaven commented 2 years ago

Update: The primary obstacle was expanding the support of an upstream dependency. sending one-off commands (which includes audio engine restart) is not built-in. I've forked the dependency and enhanced it as of https://github.com/Frosthaven/voicemeeter-connector/commit/bce957613275e020ba4fa36ba6a6e89d2b263038. This is leveraged in source code locally here: https://github.com/Frosthaven/voicemeeter-windows-volume/commit/ee977cbab55bb4c6dbc615417a374200b3b8f3f8

I have some ideas on how best to tackle firing an event on "wakeup", so with the upstream changes done it should not be too long now.

Question: Does this ONLY happen for system sleep/hibernate wakeup, or does this also occur when plugging/unplugging the monitor or having the display turn off (while not specifically asleep)?

thu2468 commented 2 years ago

It happens when either on sleep/hibernating or when display turn off image These two options

Frosthaven commented 2 years ago

I've uploaded a pre-release that has the ability to auto-restart the engine on device changes. It doesn't specifically target sleep/wake, but I'd be curious if it still triggers from the audio device change portion. If not, let me know and I'll make sleep/standby resume the next thing on the list.

Jerrk commented 2 years ago

I've uploaded a pre-release that has the ability to auto-restart the engine on device changes. It doesn't specifically target sleep/wake, but I'd be curious if it still triggers from the audio device change portion. If not, let me know and I'll make sleep/standby resume the next thing on the list.

under windows playback devices if i choose a new default playback device it takes around 20 seconds until the audio engine restarts (and sometimes it doesn't restart at all), and then when the engine restarts the volume spikes to 100%.

It seems to just randomly restart the audio engine without me touching any usb device or connecting any monitor. not quite sure what would be triggering it.

is this option supposed to work on default audio device change or is it supposed to be on a new audio device connected?

Frosthaven commented 2 years ago

is this option supposed to work on default audio device change or is it supposed to be on a new audio device connected?

it should be referencing the same list you get by running get-wmiobject win32_sounddevice in powershell. it wont show if you plug in a 3.5mm jack, as an example (since the soundcard is always "plugged in") but it should trigger on device availability changes (plugged in and removed). But I still have some expanding on it to do yet.

hows the volume syncing?

Jerrk commented 2 years ago

is this option supposed to work on default audio device change or is it supposed to be on a new audio device connected?

it should be referencing the same list you get by running get-wmiobject win32_sounddevice in powershell. it wont show if you plug in a 3.5mm jack, as an example (since the soundcard is always "plugged in") but it should trigger on device availability changes (plugged in and removed). But I still have some expanding on it to do yet.

hows the volume syncing?

volume syncing has been working for a couple versions iirc when switching default playback device like normal.

if i enable the option "restart audio engine on audio device change" the audio engine will restart randomly (in my situation atleast). and then it will spike the volume to 100% even with the "prevent 100% volume spikes" turned on.

if i restart audio engine normally it does NOT spike to 100% volume.

and in my opinion change the option from "audio device change" to "audio device connected"

Frosthaven commented 2 years ago

I've got a pre-release on the burner over here.

This adds the ability to automatically restart the audio engine when returning from sleep/hibernate/standby.

In the case that it doesn't solve this ticket:

There is no way (that I'm aware of) to track when a monitor specifically is put to sleep by the system - the only power events visible are for system-wide sleep/hibernate/modern standby.

More research would need to be done into exactly what about the monitor going to sleep causes the need for an engine restart, and likely would need to be fixed in Voicemeeter itself.

As always, I'm looking forward to your experience :)

thu2468 commented 2 years ago

image no way to detect this?

thu2468 commented 2 years ago

it is under Control Panel\Hardware and Sound\Power Options\Edit Plan Settings

Frosthaven commented 2 years ago

Not directly, no. There is no system event fired nor system log entry created when the screen goes to sleep.

What I can probably do is read that setting and then compare it to the machine's recorded idle time to approximate the event myself. It's a bit messier but it may just work. Stay tuned.

Frosthaven commented 2 years ago

Ok I have a loose method of detecting monitor wake worth testing in this pre-release.

Let me know! I'm particularly interested in if I need to delay the audio engine restart a bit more or if the timing is right as is.