Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

'SoundGet' can't find 'MICROPHONE' ComponentType in latest version (1.1.22.06)



  • Please log in to reply
8 replies to this topic
Leto
  • Members
  • 18 posts
  • Last active:
  • Joined: 11 Dec 2012
Hello,
 
I was working on a small script to control sound levels and microphone mute states, when I reinstalled AutoHotkey to update to the latest version: 1.1.22.06. Before that update, I used AutoHotkey 1.1.08, and everything was fine. Now, with 1.1.22.06, my script can't find my Microphone device anymore with the component type "MICROPHONE" by using "SoundGet".
 
I'm using Windows 7, 64 Bit.
 
The help file / change log says:
 
SoundSet, SoundGet, SoundSetWaveVolume and SoundGetWaveVolume have improved support for Windows Vista and later. Typical changes in behaviour include:
•Scripts affecting the whole system (as is usually intended) instead of just the script itself.
•Devices being numbered differently - each output or input is considered a separate device.
 
Running the "Sound Analysis Script", I observed the following differences:
 
  • Version 1.1.08: 5 mixers in the list, "MICROPHONE" component type for VOLUME and MUTE associated with mixer 5, no "ANALOG" Entries
  • Version 1.1.22: 9 mixers in the list, no "MICROPHONE" entry found, several new "ANALOG" entries, the last 2 entries are "N/A" for their component type.
 
I then muted the microsphone via Windows sound settings, ran the script again and observed that the last "N/A / MUTE" entry was now "On" (it was "Off" before), so that "N/A" entry seems to be my microphone.
 
The question is now, why is the component type of my microphone "N/A" instead of "MICROPHONE"?
 
I can't relyibly run my script know, because "N/A" as the component type for a microphone using 'SoundGet' might work for my system, but not for others.
 
I tested the behaviour with AutoHotkey 1.1.22, 32 Bit and 64 bit.
 
 
Thanks a lot for your help!
 
 
- Ben


Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

I can't relyibly run my script know, because "N/A" as the component type for a microphone using 'SoundGet' might work for my system, but not for others.

SoundGet was and is never reliable in that way on Vista or later. In older versions, SoundSet/SoundGet only affected the script's own settings (not other programs) on Windows Vista and later, unless you used XP-compatibility mode. XP-compatibility mode caused other problems and only restored some of the functionality of SoundGet. Windows Vista and later have a different audio architecture (or whatever) and the feature set available to SoundGet depends on your audio drivers, which of course vary from system to system.
 

The question is now, why is the component type of my microphone "N/A" instead of "MICROPHONE"?

The "component type" used by SoundGet is an antiquated concept that has no direct equivalent within the Vista audio system, although AutoHotkey tries to map components sensibly where possible.

If you look in the Sound control panel applet (right click the Volume icon and click Playback/Recording devices), each device listed on the "Playback" or "Recording" tab is assigned a number by SoundGet. In the Properties of each device, on the Levels tab, the controls at the top are controlled by the MASTER component of SoundGet, while each set of controls below that (if any) is a separate component (or "subunit" in the Vista API). Generally the order is the same, so if all subunits have the same type, they'll be numbered sequentially like ANALOG, ANALOG:2, ANALOG:3, etc.

However, this list of "subunits" - and therefore SoundGet's list of components - depends entirely on your audio drivers.

Did the MICROPHONE component control the recording volume of your microphone, or volume of microphone feedback through the speakers?

If feedback volume:

You can either let the user select which component to use, or you can try using VA.ahk, which allows you to specify a subunit by name. However - once again - the availability and names of subunits depends on your audio drivers (and possibly system language).

If recording volume:

Are there any other components with the same device number as your "N/A" component? IIRC, there should always be at least a MASTER component for each device, and I'm fairly certain that your Microphone will be counted as its own device. It may have both an N/A component and a MASTER component. On my work system, the "Microphone" device is simply device number 2, and it has both MASTER and WAVE components, which control the recording volume.

Currently SoundGet identifies devices only by device number. If you want to refer to devices by name instead (like "Microphone" or "Headset Microphone"), you can use VA.ahk, but the names vary depending on the audio drivers (and possibly system language). However, with VA you can easily differentiate between playback and capture/recording devices - e.g. "playback" is the default playback device and "capture:2" is the second capture device.

Leto
  • Members
  • 18 posts
  • Last active:
  • Joined: 11 Dec 2012

Hello Lexikos,

first let me say - thank you very much for your detailed answer. That gave me some insight, why SoundGet is behaving like it is.

I try to answer your questions as good as I can:

 

SoundGet was and is never reliable in that way on Vista or later. In older versions, SoundSet/SoundGet only affected the script's own settings (not other programs) on Windows Vista and later, unless you used XP-compatibility mode. XP-compatibility mode caused other problems and only restored some of the functionality of SoundGet. Windows Vista and later have a different audio architecture (or whatever) and the feature set available to SoundGet depends on your audio drivers, which of course vary from system to system.


I think this information is also part of the help file, right? I remember reading about the difference between Windows XP and Vista (and up). My requirement is only Windows 7 and later, I don't need to support Windows XP or Vista.

But the interesting part here is, why do those two AHK versions behave differently? The old one was able to find "MICROPHONE" as component type, the new one is not. While interesting, it's not the main question ;-)

 

The "component type" used by SoundGet is an antiquated concept that has no direct equivalent within the Vista audio system, although AutoHotkey tries to map components sensibly where possible.

If you look in the Sound control panel applet (right click the Volume icon and click Playback/Recording devices), each device listed on the "Playback" or "Recording" tab is assigned a number by SoundGet. In the Properties of each device, on the Levels tab, the controls at the top are controlled by the MASTER component of SoundGet, while each set of controls below that (if any) is a separate component (or "subunit" in the Vista API). Generally the order is the same, so if all subunits have the same type, they'll be numbered sequentially like ANALOG, ANALOG:2, ANALOG:3, etc.

However, this list of "subunits" - and therefore SoundGet's list of components - depends entirely on your audio drivers.


Thanks a lot - yes, I could see exactly what you described.

My Microphone is a "RODE NT-USB", which is an USB device (so, it's own device) but not only a recording device, but also a playback device, because you can plug in your headphones to hear a feedback of your own voice, mixed the the computer sounds. To plugging in the microphone means there appears a recording device AND a playback device in the Windows sound settings. This is not a problem, just an explanation.

Here is an image of the sound card analyzing script, a comparison between the results without and with the microphone plugged in:

2015-09-16_ahk_SoundGet_comparison.png?d


 

Did the MICROPHONE component control the recording volume of your microphone, or volume of microphone feedback through the speakers?


The "MICROPHONE" component type (using the older AHK version) had the control types "VOLUME" and "MUTE". The "VOLUME" controlled the recording level of the microphone, not the feedback volume through the speakers.


 

If recording volume:

Are there any other components with the same device number as your "N/A" component?
IIRC, there should always be at least a MASTER component for each device, and I'm fairly certain that your Microphone will be counted as its own device. It may have both an N/A component and a MASTER component. On my work system, the "Microphone" device is simply device number 2, and it has both MASTER and WAVE components, which control the recording volume.


Is the "device number" the number displayed in the "Mixer" column of the sound analyzing script?

Looking at the image above, yes, it seems that the microphone is there as "N/A" and also as "MASTER", mixer number 9.
 

Currently SoundGet identifies devices only by device number. If you want to refer to devices by name instead (like "Microphone" or "Headset Microphone"), you can use VA.ahk, but the names vary depending on the audio drivers (and possibly system language). However, with VA you can easily differentiate between playback and capture/recording devices - e.g. "playback" is the default playback device and "capture:2" is the second capture device.


Reading your explanations, I think this is the best solution for me. It is no problem (usability-wise) to show a list of recording devices for the user and let him choose the correct device/microphone, especially when the device names are different on different systems.

So, I will have a look at "VA.ahk" - thanks again for your detailed help, Lexikos!


(I will, if I may, give feedback here about my progress..)


Kind regards,
Ben



Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

The old one was able to find "MICROPHONE" as component type, the new one is not.


The short answer is that XP and earlier exposed audio devices in a totally different way to Vista and later. SoundGet pre-v1.1.10 reflected how the old system works, whereas SoundGet v1.1.10+ (when not in XP compatibility mode) reflects how the new system works.


In the old system, MICROPHONE probably means the microphone input component of your audio hardware.

In the new system, playback (e.g. Speakers) and recording (e.g. Microphone) are represented as two completely independent "devices". To control the recording volume, you adjust the MASTER volume of the recording device. MICROPHONE should mean a subunit whose source is the microphone, but if the device you've selected is a playback device, it will probably adjust the volume of microphone feedback through the speakers.

In either system, I think it really depends on whoever designed your audio drivers.


When you use the old API on a new OS, one of two things happen:
  • By default, the OS pretends to do what you ask but really only changes the settings of your own process. (Larry Osterman explains why.)
  • If your process is running in XP compatibility mode, the OS tries to behave as if you were running XP. Exactly what the OS does is a mystery to me, but in my experience it is usually lacking some components/controls and heavily dependent on your audio drivers.
I'd have to assume you were either running in XP compatibility mode or running on XP or earlier, otherwise your script should not have worked.

You can't be running in XP compatibility mode anymore, because if you were, you would get the old behaviour (because AutoHotkey thinks you're running it on XP!). Unless you're actually on a different computer now, or have installed a different OS.
 

When I use the soundcard analysis script with AutoHotkey.exe set to run in XP-compatibility mode, I get this:
MASTER  MUTE    Off     1
LINE    VOLUME  0.00    1
LINE    MUTE    Off     1
WOW. On my system, the old API does not even support retrieving the master volume. (This is probably related to the fact that my hardware is very new.)

With the new API, there are 5 devices - actually corresponding to two outputs (analog and optical) and three inputs (front mic, rear mic and rear line in). The first device ("Speakers") has "Microphone" and "FrontMic" subunits which SoundGet represents as MICROPHONE and MICROPHONE:2.

However, these MICROPHONE components control the volume of sound feeding back through my speakers. They do not control the recording volume; for that, there is a totally separate "device".
 

Is the "device number" the number displayed in the "Mixer" column of the sound analyzing script?

SoundGet doesn't have a "Mixer" parameter; it has a "DeviceNumber" parameter. But yes, it's the same thing.
 

Looking at the image above, yes, it seems that the microphone is there as "N/A" and also as "MASTER", mixer number 9.

So does adjusting the MASTER component (or omitting the ComponentType parameter) have the desired effect?
 

I try to answer your questions as good as I can:

I only asked one question, and it was to help you decide which part of my post was relevant to your situation.

Leto
  • Members
  • 18 posts
  • Last active:
  • Joined: 11 Dec 2012
Hello Lexikos,
 
thanks again for your help!
 

 

The short answer is that XP and earlier exposed audio devices in a totally different way to Vista and later. SoundGet pre-v1.1.10 reflected how the old system works, whereas SoundGet v1.1.10+ (when not in XP compatibility mode) reflects how the new system works.
 
In the old system, MICROPHONE probably means the microphone input component of your audio hardware.
 
In the new system, playback (e.g. Speakers) and recording (e.g. Microphone) are represented as two completely independent "devices". To control the recording volume, you adjust the MASTER volume of the recording device. MICROPHONE should mean a subunit whose source is the microphone, but if the device you've selected is a playback device, it will probably adjust the volume of microphone feedback through the speakers.
 
In either system, I think it really depends on whoever designed your audio drivers.

 

 
Thanks for this explanation, it now makes sense to me and, as a follow-up, I read about the changes of the sound system in Windows Vista.
 
 

 

When you use the old API on a new OS, one of two things happen:
  •  
  • If your process is running in XP compatibility mode, the OS tries to behave as if you were running XP. Exactly what the OS does is a mystery to me, but in my experience it is usually lacking some components/controls and heavily dependent on your audio drivers.
 
 
I'd have to assume you were either running in XP compatibility mode or running on XP or earlier, otherwise your script should not have worked.

 

 
As in my first post stated, I ran the script with Windows 7 64 Bit.
 

 

You can't be running in XP compatibility mode anymore, because if you were, you would get the old behaviour (because AutoHotkey thinks you're running it on XP!). Unless you're actually on a different computer now, or have installed a different OS.
 
When I use the soundcard analysis script with AutoHotkey.exe set to run in XP-compatibility mode, I get this:
 
[...]
 
So does adjusting the MASTER component (or omitting the ComponentType parameter) have the desired effect?

 

 
Yes, the MASTER component of my Microphone-Device (the hardware device, not the subunit) controls the sound-feedback-level. The "N/A" component (which was "MICROPHONE" with the old AHK version) controls the recording level. These are, like you've said, two different "devices" (playback and recording).
 

 

I only asked one question, and it was to help you decide which part of my post was relevant to your situation.

 

 
Yes, you are right of course :) I just started my answer with these words, assuming there is more than one question. I always think that, when someones takes his time to write such a detailed answer like you, he deserves a good answer.
 
So, I think you taught me a lot about the differences in those sound APIs, and that it depends on the sound drivers, in the end.
 
I wasn't able to test "VA.ahk" yet, but I will have the time this weekend.
 
 
Thank you!


Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Yes, the MASTER component of my Microphone-Device (the hardware device, not the subunit) controls the sound-feedback-level. The "N/A" component (which was "MICROPHONE" with the old AHK version) controls the recording level. These are, like you've said, two different "devices" (playback and recording).

By "sound-feedback-level" do you mean the output volume of your headphones when plugged into your device? Two different devices means two different device numbers. Are you comparing the MASTER component of one device number to the N/A component of a different device number?

My question was about the MASTER component of the same device; i.e. device number 9. If N/A belongs to a recording device, the MASTER component will control the recording volume. I do not think it is possible for a device to not have a MASTER component, although I can see in your screenshot that some of your devices have a MASTER component which cannot be retrieved.

It should work like this:

Program <-- |MASTER volume| <-- |MASTER mute| <-- |N/A volume| <-- |N/A mute| <-- Source(microphone)

For each source, there is a path from source-connector to target, which can run through one or more subunits which affect processing; such as volume, mute, treble, bass, etc. It is sometimes possible to adjust the volume at multiple points if there are multiple volume subunits.

When I mentioned "feedback" before ("microphone feedback through the speakers"), I meant that the audio drivers can accept input from the microphone and feed it back directly through the speakers. Like a loud-speaker, if you speak into the microphone, you can hear your own voice come out of the speakers. Usually the Levels tab of a playback device's properties will have some like this -- my work system has "Front Pink In", "Rear Pink In" and "Rear Blue In" which are feedback controls, and "Center", "Subwoofer", "Rear" and "Front", which presumably control surround sound output.

Leto
  • Members
  • 18 posts
  • Last active:
  • Joined: 11 Dec 2012

Hello Lexikos,
 

By "sound-feedback-level" do you mean the output volume of your headphones when plugged into your device? Two different devices means two different device numbers. Are you comparing the MASTER component of one device number to the N/A component of a different device number?

My question was about the MASTER component of the same device; i.e. device number 9. If N/A belongs to a recording device, the MASTER component will control the recording volume. I do not think it is possible for a device to not have a MASTER component, although I can see in your screenshot that some of your devices have a MASTER component which cannot be retrieved.


Oh I'm sorry - I mixed up some things here, sorry for the confusion. Yes, it was the same mixer/device ID, and the MASTER of the microphone-device controlled it's recording volume, exactly as you explained earlier.

Meanwhile, I tested your VA.ahk library, and so far it works like a charm. For me, it is more straightforward and understandable than 'SoundGet' / the old sound API before Vista.

With VA.ahk, I now retrieve all available recording devices ("capture") and present the user their names ("VA_GetDeviceName"). The user can then choose the correct microphone (which is a good thing, because the user sees the actual name, in my case "RODE NT-USB"). After that, controlling the recording volume ("VA_SetMasterVolume") and mute state ("VA_SetMasterMute") is really easy.

To retrieve all available devices, I use the following code:

Loop
{
    soundDevice := VA_GetDevice( "capture:" . A_Index )
    if ( ! soundDevice )
        break

    ; Do something with 'soundDevice', e.g. collecting it's name

    ObjRelease( soundDevice )
}

Since there is no function for enumerating all sound devices in VA.ahk, I had to use such a loop. Is this a good way to do it?



Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
That's the easiest way. The other way is to use the Vista audio API directly. soundcard.ahk posted here does this; for instance, the VA_IMMDeviceEnumerator_EnumAudioEndpoints function corresponds to the IMMDeviceEnumerator::EnumAudioEndpoints method.

Leto
  • Members
  • 18 posts
  • Last active:
  • Joined: 11 Dec 2012
✓  Best Answer

Hello Lexikos,

 

That's the easiest way. The other way is to use the Vista audio API directly. soundcard.ahk posted here does this; for instance, the VA_IMMDeviceEnumerator_EnumAudioEndpoints function corresponds to the IMMDeviceEnumerator::EnumAudioEndpoints method.

 

ok I see - I will stick with the loop, since I do not have to repeat that in my script very often.

 

 

So, I think this topic is solved - Lexikos, thanks a lot for your help!

 

 

- Ben