Adjust Mic Volume Level?

[sl23]

The DLL is obviously at fault...

Yeah but you don't even need to use it. As long as the skin is active, Rainmeter's memory usage in Task Manager goes up every second or so and never stops! Just the fact it is loaded is enough. But perhaps you are right in thinking it's a combination of factors causing it?

See here or here and adapt it to your needs.

That being said, I'm not sure you'd need that, since a simple Get-PnpDevice (or even Get-PnpDevice | format-list for a more detailed view) will list everything in the PS window, and you can do tests there, make sure whatever command to enable disable the desired device works, before incorporating that command in your Rainmeter skin:

I'm not really understanding what you're getting at here. My intention was to use the copy and paste of DeviceList to update a set of Variables, that way if a skin is moved to another PC, clicking a button would update it. This is only required for the InputDevice though. Thanks for the links though, that gave me something to work with!

[Yincognito]

Yeah but you don't even need to use it. As long as the skin is active, Rainmeter's memory usage in Task Manager goes up every second or so and never stops! Just the fact it is loaded is enough. But perhaps you are right in thinking it's a combination of factors causing it?

In my previous tests, if I commented out the [InputVolume] measure and still kept the DLL loaded, the memory usage seemed to stall, but maybe I wasn't paying enough attention, or maybe it just grew but by a much smaller amount. I did set UpdateDivider=-1 on the parent measure, but it works either way. For example, simplifying things a bit and making some small adjustments to the script and code...

[SkinFolder]\@Resources\Addons\AudioDeviceCmdlets.dll

[SkinFolder]\@Resources\DeviceVolume.ps1:

Code: Select all

Import-Module -Name "$($RmAPI.VariableStr('@'))Addons\AudioDeviceCmdlets"

function Get-OutputVolume
{
  if (Get-AudioDevice -PlaybackMute) {return -1} else {return (Get-AudioDevice -PlaybackVolume).replace('%','')}
}

function Get-InputVolume
{
  if (Get-AudioDevice -RecordingMute) {return -1} else {return (Get-AudioDevice -RecordingVolume).replace('%','')}
}

function Set-OutputVolume
{
  Set-AudioDevice -PlaybackVolume $RmAPI.Variable('OutputVolume')
}

function OutputToggle-Mute
{
  Set-AudioDevice -PlaybackMuteToggle
}	

function Set-InputVolume
{
  Set-AudioDevice -RecordingVolume $RmAPI.Variable('InputVolume')
}

function InputToggle-Mute
{
  Set-AudioDevice -RecordingMuteToggle
}

function Finalize
{
  Remove-Module -Name "AudioDeviceCmdlets"
}

[SkinFolder]\Test.ini:

Code: Select all

[Variables]

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1

[DeviceVolume]
Measure=Plugin
Plugin=PowershellRM.dll
ScriptFile=#@#DeviceVolume.ps1
UpdateDivider=-1

[InputVolume]
Measure=Plugin
Plugin=PowershellRM.dll
Parent=DeviceVolume
Line=Get-InputVolume

[Result]
Meter=String
SolidColor=47,47,47,255
FontColor=255,255,255,255
FontFace=Consolas
FontSize=16
AntiAlias=1
MeasureName=InputVolume
Text=Input Volume: %1%
DynamicVariables=1

InputVolume.jpg

is stable for me, at between 56 and 63 K and doesn't seem to rise above that for the time I tested it. For the record, the memory usage before loading the skin (using my suite, as seen above) was 40 K, so the additional usage is around 16 and 23 K from PS + PowershellRM.

EDIT: Setting the update to 50 ms instead of 1 s does trigger the memory leak though, so as I said before, I guess it's a combination of factors - maybe PS or PowershellRM needs some time to dispose / release memory, I don't know.

I'm not really understanding what you're getting at here. My intention was to use the copy and paste of DeviceList to update a set of Variables, that way if a skin is moved to another PC, clicking a button would update it. This is only required for the InputDevice though. Thanks for the links though, that gave me something to work with!

What I was getting at is that you can use the "friendly names" or the IDs that PS itself provides in order to enable or disable your microphone via the commands I already linked to here, assuming you find out which "friendly name" or ID it has. I can't do the latter part for you, as my system is different from yours, obviously. If you still want to explore that avenue, that is.

[sl23]

That's great thanks for that info
When I get some more free time I'll get back onto this.

I know I could remove the fft measures to increase the update to 1s but, I didn't really want to. There's obviously a problem that is magnified with faster update rates. I don't know how to report this on github as I find github a bit hit and miss trying to find stuff sometimes. Maybe that's just me? Lol

Thank you again for your time and effort to try and resolve this thing

[Yincognito]

That's great thanks for that info
When I get some more free time I'll get back onto this.

I know I could remove the fft measures to increase the update to 1s but, I didn't really want to. There's obviously a problem that is magnified with faster update rates. I don't know how to report this on github as I find github a bit hit and miss trying to find stuff sometimes. Maybe that's just me? Lol

Thank you again for your time and effort to try and resolve this thing

Well, you can always set an UpdateDivider on the relevant measure only, which would guarantee that everything else works at the same frequency...

[sl23]

Oh of course, I knew that!

[sl23]

Setting the update to 50 ms instead of 1 s does trigger the memory leak though, so as I said before, I guess it's a combination of factors - maybe PS or PowershellRM needs some time to dispose / release memory, I don't know.

Maybe you're right and it needs time to release the memory? But the update rate doesn't stop the leak when set to 1s, it slows it right down. You can see this by setting it to 50ms and slowly increase the time. You'll notice with each increase the update in Task Manager shows it accordingly.

This is all really just for information, as it needs to be reported.

Well, I tried using the "friendly names" but still I get the error:

Code: Select all

Enable-PnpDevice : Generic failure
At line:1 char:90
+ ... '*Microphone (Realtek(R) Audio)*'} | Enable-PnpDevice -Confirm:$false
+                                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (Win32_PnPEntity...}.{2D70EDF0...):ROOT\cimv2\Win32_PnPEntity) [Enable-Pnp
   Device], CimException
    + FullyQualifiedErrorId : HRESULT 0x80041001,Enable-PnpDevice

When you say "friendly name" do you mean for example: Microphone (Realtek(R) Audio) or just Microphone? Do I need to keep the ** around the name?

[Yincognito]

Maybe you're right and it needs time to release the memory? But the update rate doesn't stop the leak when set to 1s, it slows it right down. You can see this by setting it to 50ms and slowly increase the time. You'll notice with each increase the update in Task Manager shows it accordingly.

You don't see the 1 s update leak by changing the update back to 50 ms - they are different situations, and different conclusions. Point is, if the update is set to 1 s, the leak, while it may exist technically, is kept under control and the memory usage doesn't go past a certain value (63 K in my case, might be different for you). So you're right that the leak exists and has to be reported, but setting the update to 1 s acts as a damage control, so to speak. So far, it's the best solution you got, if you're ok with keeping the DLL / PS session / measure active.

Well, I tried using the "friendly names" but still I get the error:

Code: Select all

Enable-PnpDevice : Generic failure
At line:1 char:90
+ ... '*Microphone (Realtek(R) Audio)*'} | Enable-PnpDevice -Confirm:$false
+                                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (Win32_PnPEntity...}.{2D70EDF0...):ROOT\cimv2\Win32_PnPEntity) [Enable-Pnp
   Device], CimException
    + FullyQualifiedErrorId : HRESULT 0x80041001,Enable-PnpDevice

When you say "friendly name" do you mean for example: Microphone (Realtek(R) Audio) or just Microphone? Do I need to keep the ** around the name?

The friendly name is the complete humanly readable name of that device, probably Microphone (Realtek(R) Audio) in your case (if it's the entire string corresponding to your microphone, that is). The * are just wildcards, so *Microphone* can mean SomePrefixHere Microphone or Microphone SomeSuffixHere, or just plain Microphone without any pre- or post- additional characters. It's the simpler equivalent of .* from regex, basically.

You'd have to test your devices and see which one is it, or disabling / enabling which one produces the effect you want. I didn't go to great lengths in my case since I don't have your system, but as an example, some stuff works, some doesn't - you just have to find which device is the one you need to disable / enable:

DisableEnableMicArray.jpg

Now, I'm pretty sure this is not exactly what I wanted (e.g. disable the mic from my headset), but maybe it comes close to it, if it's a child of the mic array. Didn't test to see the effect, but keep experimenting and you'll find the solution eventually. I'm not sure if I couldn't set the mic from my headset because the headset wasn't plugged in at that time or because its status was "Unknown", but you get the idea. You can try running Get-PnpDevice -PresentOnly -Status ERROR before disabling your mic manually from Settings, then compare that list with the one you get after running the command a second time, after disabling it, in order to identify which device exactly is Windows disabling when you do it manually. Then, you should be able to use Get-PnpDevice | Where-Object {$_.FriendlyName -like 'TheDeviceYouJustIdentified'} | Enable-PnpDevice -Confirm:$false or its disable equivalent and get the desired effect. This is based on the fact that for me, the Status of my mic array after disabling is "ERROR" (this is also the status of my printer which wasn't plugged in at the time, by the way), so it's clear that this status can be an indication of the device being disabled. Of course, it might just happen to not be able to enable a device if it isn't plugged in, as you progress with the procedure, but that's another story.

[sl23]

Point is, if the update is set to 1 s, the leak, while it may exist technically, is kept under control

Yeah understood.
I've tried some stuff out very quick, can't seem to get anything to work wrt powershell, just get that same error!
Need more time to look at it properly, probably just missing something silly?!

Thanks...

[Yincognito]

Yeah understood.
I've tried some stuff out very quick, can't seem to get anything to work wrt powershell, just get that same error!
Need more time to look at it properly, probably just missing something silly?!

Thanks...

Not silly, but probably some detail. Does this work?

Code: Select all

Get-PnpDevice | Where-Object {$_.FriendlyName -like '*Microphone Array*'} | Enable-PnpDevice -Confirm:$false

[sl23]

Tried it twice and nothing happened!

Code: Select all

PS C:\Users\sl23> Get-PnpDevice | Where-Object {$_.FriendlyName -like '*Microphone Array*'} | Enable-PnpDevice -Confirm:$false
PS C:\Users\sl23> Get-PnpDevice | Where-Object {$_.FriendlyName -like '*Microphone Array*'} | Enable-PnpDevice -Confirm:$false
PS C:\Users\sl23>

Also tried Disabling to see if it affected anything, but nothing changed.