mtkennerly
commented
1 week ago Hi! Do you have the code for the radio archival program? I'm curious what APIs it's using to check the system volume.
I did a quick test, and it works for me with a service running as Local System, although I'm using Windows 11 Home and I'm logged in at the same time. Do you think it's specific to Pro and Enterprise? Does it make any difference for you if you're logged in vs logged out while the service is running?
Here's the program I used for testing. Could you give it a try, just to rule out anything specific to your archival program? It's a modified version of the shawl-child test program from this repo:
Set up: shawl.exe add --name shawl-audio -- C:\path\to\shawl-child.exe
For transparency, it has these changes:
diff --git a/Cargo.toml b/Cargo.toml
index ef8c291..94b09b5 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -16,6 +16,7 @@ dunce = "1.0.4"
flexi_logger = "0.27.3"
log = "0.4.20"
winapi = { version = "0.3.9", features = ["consoleapi", "errhandlingapi", "winbase", "wincon"] }
+windows = { version = "0.57.0", features = ["Win32_Media_Audio", "Win32_Media_Audio_Endpoints", "Win32_System_Com"] }
windows-service = "0.6.0"
[dev-dependencies]
diff --git a/src/bin/shawl-child.rs b/src/bin/shawl-child.rs
index c08aebb..965adee 100644
--- a/src/bin/shawl-child.rs
+++ b/src/bin/shawl-child.rs
@@ -48,6 +48,31 @@ fn prepare_logging() -> Result<(), Box<dyn std::error::Error>> {
Ok(())
}
+fn get_volume() -> windows::core::Result<f32> {
+ use windows::Win32::{
+ Media::Audio::{
+ eConsole, eRender, Endpoints::IAudioEndpointVolume, IMMDeviceEnumerator,
+ MMDeviceEnumerator,
+ },
+ System::Com::{
+ CoCreateInstance, CoInitializeEx, CLSCTX_ALL, CLSCTX_INPROC_SERVER,
+ COINIT_APARTMENTTHREADED,
+ },
+ };
+
+ unsafe {
+ CoInitializeEx(None, COINIT_APARTMENTTHREADED).ok()?;
+ let device_enumerator: IMMDeviceEnumerator =
+ CoCreateInstance(&MMDeviceEnumerator, None, CLSCTX_INPROC_SERVER)?;
+ let device = device_enumerator.GetDefaultAudioEndpoint(eRender, eConsole)?;
+
+ let endpoint_volume: IAudioEndpointVolume = device.Activate(CLSCTX_ALL, None)?;
+ let volume = endpoint_volume.GetMasterVolumeLevel()?;
+
+ Ok(volume)
+ }
+}
+
fn main() -> Result<(), Box<dyn std::error::Error>> {
prepare_logging()?;
info!("********** LAUNCH **********");
@@ -80,7 +105,7 @@ fn main() -> Result<(), Box<dyn std::error::Error>> {
while running.load(std::sync::atomic::Ordering::SeqCst) {
std::thread::sleep(std::time::Duration::from_millis(500));
- info!("Looping!");
+ info!("Volume: {:?}", get_volume());
}
info!("End");And here's an excerpt of the log output from the service (0.0 is max volume, -65.25 is min volume):
2024-06-24 23:03:39 [DEBUG] stderr: "[INFO] Volume: Ok(-15.164473)"
2024-06-24 23:03:48 [DEBUG] stderr: "[INFO] Volume: Ok(-28.66002)"
2024-06-24 23:03:49 [DEBUG] stderr: "[INFO] Volume: Ok(-30.776678)"
2024-06-24 23:03:52 [DEBUG] stderr: "[INFO] Volume: Ok(-65.25)"
2024-06-24 23:03:57 [DEBUG] stderr: "[INFO] Volume: Ok(0.0)"
2024-06-24 23:03:57 [DEBUG] stderr: "[INFO] Volume: Ok(-11.885729)"
bluebrook-sean
I have a use case experience that may (?) suggest an additional step when setting up a service wrapper under Windows 11, perhaps due to a change in permissions management. I don't work in Windows IT, and apologize if I've just missed something that should be obvious about how to use Windows 11.
I have desktop Windows software that processes audio inputs, and I'm using it for archiving two-way radio communications. In some contexts, it needs to run without a Windows user logged in, so (about a decade ago) I added XYNT as a wrapper. With Windows 11 Pro and Enterprise, the software in service mode sees the audio ports but with zero levels (but it works in desktop mode). My impression is that this is related to a change in Windows audio permissions, because the zero level symptom matches expected behavior when permissions have not been granted. I'd think LocalSystem would have permissions to do nearly anything, and I've found no way to access permissions for this user.
Because of this problem, I tried alternatives to XYNT, including shawl and Fire Daemon Pro (FDP). With FDP it works (out of the box, no special configurations entered), so I believe it is possible for a wrapper to support or enable access to audio. With shawl, I see the same symptom as under XYNT. Surprisingly, this is true even when launching the service under a Windows user where the desktop software has been granted audio input (called microphone, even when it's not a mic) permissions. I feel Windows 11 has introduced some kind of obstacle to service mode audio access, and based on my experience with FDP, overcoming this issue may be an additional step to be done in the wrapper.
Shawl is my preference going forward over XYNT (maintained - XYNT is 12 years old) and FDP (shawl is lightweight, easier to integrate). But right now I have not found a way to make this work (have the software see audio levels while running under shawl on these versions of Windows 11).