Default audio device changed, marking master sessions as stale

[adamdiel]

I am on a new build with a fresh windows 11 install. If my computer goes into sleep and comes back I get the following error message

2023-10-09 16:46:59.368 DEBUG   deej.session_finder             Default audio device changed, marking master sessions as stale

If I simply stop/restart the exe it connects just fines and starts working immediately.

Let me know what other info I can provide!

[omriharel]

Hi @adamdiel, thanks for writing.

Can you please clarify if there is any functional change to the regular operation of deej after you see this log message?

This isn't an error - it is a debug log from an internal mechanism in deej which tracks changes to your default audio playback device so that the pot you have bound to master sticks to whatever your current output device is.

If you are having issues reconnecting after waking your PC from sleep (which aren't related to this log message), that would be a duplicate of other related open issues such as #23 and #38. In that case, this will be fixed in a future update and you should follow those issues for an update (or our #annoucements channel on the project's community Discord server). In the meantime your current workaround of stopping and restarting deej would continue working for you.

Please let me know if you have any questions!

[adamdiel]

Thanks for the quick reply @omriharel !

Gotcha - I should have investigated the timestamp a little bit closer to see if it matched up.

I'll make sure to watch the Discord server! The other thing I'm going to to try is to set my power profile to high performance instead of balanced. This is the only difference I can find between my old windows 10 install and current windows 11 install.

I'll close the issue for now but if I see any change in behavior I'll report back!

[omriharel]

Thanks for the update! Feel free to let me know if you observe any new behaviors.

[adamdiel]

Alright reopening. I've noticed some interesting behavior that may or may not be related to deej.

So I noticed that sometimes my mouse/keyboard wouldn't wake my computer from sleep but not all the time. I figured this was a windows hibernation or a bios setting. After checking that all of that was set correctly, I started testing different ports on the tower.

I had deej running in debug and regular mode on and off throughout testing putting my computer to sleep and seeing when my mouse/keyboard would or wouldn't work to wake my device.

Findings:

1. When deej was running and the computer went to sleep, when it woke up it would always display at least one Default audio device changed, marking master sessions as stale message even though the device was the same before and after sleep.
2. If deej was running and working before putting my computer to sleep mode, the mouse and keyboard would never wake the computer from sleep.
3. If deej was running but broken (because of the computer previously going to sleep) and it goes to sleep again, the mouse and keyboard work to wake the computer.
4. If deej is closed, the mouse and keyboard work in waking the computer from sleep.

Hopefully this info is helpful and let me know if there is any other info that I can provide such as hardware. Thats the only difference between where this was running and where its running now. Same hardware and slider mappings as the other box.

Here is my current config file

# process names are case-insensitive
# you can use 'master' to indicate the master channel, or a list of process names to create a group
# you can use 'mic' to control your mic input level (uses the default recording device)
# you can use 'deej.unmapped' to control all apps that aren't bound to any slider (this ignores master, system, mic and device-targeting sessions) (experimental)
# windows only - you can use 'deej.current' to control the currently active app (whether full-screen or not) (experimental)
# windows only - you can use a device's full name, i.e. "Speakers (Realtek High Definition Audio)", to bind it. this works for both output and input devices
# windows only - you can use 'system' to control the "system sounds" volume
# important: slider indexes start at 0, regardless of which analog pins you're using!
slider_mapping:
  0: master
  1: mic
  2: chrome.exe
  3: deej.current
  4: discord.exe
  5: XboxPcApp.exe

# set this to true if you want the controls inverted (i.e. top is 0%, bottom is 100%)
invert_sliders: true

# settings for connecting to the arduino board
com_port: COM3
baud_rate: 9600

# adjust the amount of signal noise reduction depending on your hardware quality
# supported values are "low" (excellent hardware), "default" (regular hardware) or "high" (bad, noisy hardware)
noise_reduction: low

[omriharel]

Hey @adamdiel,

I'll comment on some of your findings, but I will preface by saying that:

• Based on the nature of these things being closely related to USB power management (which depend entirely on your motherboard/BIOS), it's very likely that even though you're able to observe a correlation between deej running and wake-related functions not working as you normally expect (and the opposite) - the actual cause for it stems from having an active serial connection (and not due to some implementation details specific to deej).
• In addition, due to the highly variable nature of hardware setups, it is very difficult for individuals to reproduce issues like this
• Finally, I would like to clearly make a distinction between the serial connection becoming broken and not automatically restored after sleep (which happens, again, only on some setups - and is a known issue that's actively worked on) and other observable behaviors which you're describing above (which aren't being researched at the moment).

With that in mind:

• On point 1: The "marking master as stale" message, as described, is an internal mechanism that tracks changes to the default audio device. If it appears, it means that the OS reported that the default audio device had been changed. It doesn't necessarily mean anything for you, because it might just be power-cycling (for example if it's USB-powered, like some headphones) - but you shouldn't associate it with any adverse effects
• On points 2 to 4: they all suggest that having an active serial connection while the computer goes to sleep prevents USB wake from other devices. You can try to test if other serial connections to an Arduino board (that aren't deej) produce the same behavior, but I don't have much else to say about that - I don't consider it a deej issue at the moment

I suppose you could also continue tweaking various power management settings in your OS and BIOS, but I lack deep knowledge about this subject.

[adamdiel]

Hey great points! I'll have to decomission another project so might take me a few days but I'll try a non deej connection and see if I can get the same behavior!

I figured for point 1 that would be the case but figured it was worth a data point.

So to confirm my understanding - the serial connection not being restored after sleep is a known issue and being investigated however an active serial connection affecting other devices from waking a device would be outside the scope.

Anyways - I'll do some more experiments and see if I can provide any other useful data points!

[omriharel]

So to confirm my understanding - the serial connection not being restored after sleep is a known issue and being investigated

Yes, tracked in the duplicate issues I pointed at earlier and will be fixed in the next version of deej (which in general will make the connection mechanism a lot more robust and intuitive than it currently is).

however an active serial connection affecting other devices from waking a device would be outside the scope

Correct, because my suspicion is that this isn't a problem unique to deej (even though deej is one possible way to cause it, because it maintains an active long-term serial connection).

I'll close this for now but feel free to post more data below later on if you collect it.