Matching Cal files with Multiple USB Mics on Windows

[pdiprete]

I'll start simple and add detail as needed throughout the thread if we get there. I'm hoping I'm being dense, and there's some easy mapping I'm missing, but I can't for the life of me figure out how to identify which mic is which when plugged into one of 4 ports on the USB hub.

I have the multi-input capture license, and I'm using 4 UMIK-4 mics on a single USB3 4 port hub under Windows 10. I have the 4 calibration files for the mics. I cannot consistently identify the microphones in REW, and I can't seem to name them uniquely. Therefor, I can't seem to consistently associate the calibration file with the correct mic.

Mic order in REW does not seem to correlate either with the port on the hub, the order in which the mics are connected or the order the devices appear in the ASIO4ALL control panel.

In ASIO4ALL Control Panel, hovering over the device name identifies the port # on the USB hub, so I can map from physical ports to ASIO4ALL. What's the correlation between Mics in ASIO4ALL control panel and REW?

Can I uniquely name microphone devices? Renaming them in Windows' Device Manager doesn't carry through to ASIO4ALL or REW.

Is it possible that the order in which the mics show up in REW is the order in which Windows first saw them? If so, that's not so bad; I can delete all the UMIK-2 devices then attach them in the order I want.

Thanks in advance and apologies for droning on.

 

[John Mulcahy]

When you say UMIK-4 you meant to type UMIK-2, I guess. ASIO4All decides the order devices appear and their labels, I don't know how it decides that though. REW asks the ASIO driver for the list of inputs and presents that list in the order they are provided.

The Windows name for devices gets captured in the registry when the device is first connected, and usually stays the same even if the device changes part of its name or description afterwards. Devices with the same name on different ports usually get a number added to the end of the name. I suspect that editing the relevant registry key for each mic would allow them to get whatever name you like, but would need some poking around to locate them. If there doesn't seem to be a logical order to the way the mics appear you can always revert to tapping the end of the mic and watching the Levels meters, but tedious to keep having to do that.

Note that you will need to make sure that the input volume is set the same for all the mics.

 

[pdiprete]

John:

UMIK-2, yup. That was a typo. I've deleted all the UMIK microphone devices in the device manager and am currently poking around the registry making sure I've cleaned up everything or identified all the detritus before starting to add things back one by one.

If I'm successful, I'll be able to identify the particular properties that get passed from Windows to ASIO4ALL to REW, so we can maybe simplify this process and make it more deterministic.

Any ASIO4ALL experts out there?

More in a bit (likely tomorrow).

 

[pdiprete]

John:

There are 2 parts to the process to identify the microphone order in REW, and the order does not track with either the port order on the hub or the order in which the microphones are plugged into Windows in that session. The first step is to determine the Location information, which includes the port #, for each microphone; this comes from Windows. The second is to determine the order in which ASIO4ALL is handing those to REW; you have to open the ASIO4ALL control panel to get this info.

The easiest way to quickly and repeatedly identify the microphones is by using a free USB viewing utility like USBTreeView (the upper image in the first screenshot, or "1"). You can also get the same information from Windows with a lot more clicking ("2" below).

I found it helpful in my debugging to name the microphones uniquely, but those properties (Display Name and Friendly Name) don't seem to pass through ASIO4ALL; I didn't need that extra hint once I'd confirmed the USB Port # mapping (right to left, in my case, though I know many others that number the ports left to right or in even more interesting ways).

USBTreeView simplified the process of iterating quickly, but it's strictly optional. To get the information from Windows, don't use the Device Manager (while it is very likely to show the location information the first time, after a restart or two, Windows gets cute and winds up hiding that information by being helpful and giving you the same friendly name for the connection for all the microphones (in my case, "UMIK." Gee thanks). Instead use Sound Settings:

1. Right Click on your sound device (the speaker in the task bar)
2. Choose "Open Sound Settings"
3. Select each microphone in order ("Choose your input device")
4. Click into "Device Properties"
5. Optionally rename the microhphone on this properties page
6. Click into "Additional Device Properties"
7. Click "Properties" in the Controller Information pane
8. Finally, "Location" is displayed on the General tab of the new properties sheet that shows ()

I honestly downloaded, installed and ran USBTreeView in the time that it took to repeat that process twice for the first 2 mics.

Armed with the location information, open ASIO4ALL's control panel and "hover" over each microphone instance in the list. The location information is revealed in the screentip that pops up (for something like 5 seconds). The fifth (5th) field in that string identifies the USB Port #, and the location strings match exactly what Windows reports.

So far, the microphone mapping appears to be stable, but I haven't done enough testing to be sure. At least I have a goofy but deterministic method.

Thanks for the hint in your first response, that unlocked the door.

 

[pdiprete]

John:

After further testing, I've characterized the behavior of ASIO4ALL and REW with respect to USB microphones. I wrote that up as a feature request and posted it in another thread on this forum. I did that, because I saw that others had begun to request features this way; let me know if that was wrongheaded.

In the process of debugging, I've broken "Measurement." All my test sweeps are distorted. I've painstakingly ensured that each mic has the same sample rate and bit depth, but I still get distortion on sweeps at any volume.

In the process, I noticed that ASIO4All reports "32 bits" for the devices even when I set them to 24 (mostly to be consistent with the display as I test).

I'm using HDMI output to either an Emotiva UMC-200 (running firmware 52) and Marantz 7703 (up to date, but the version # escapes me). Each mic is connected to the same (cheap, "Insignia" from Best Buy) USB3 hub. The hub is directly connected to the laptop (Dell XPS13 running Windows 10), and the laptop itself is directly connected to the UMC-200 using a 2 meter Audioquest Carbon cable. In other words, this is not likely to be a connectivity or hardware incompatibility issue.

From memory, after uninstalling and reinstalling REW, this problem went away last time. That's what I'm going to try in the morning. If you come up with any ideas for me to try in the morning, by all means, do tell.

 

[sm52]

pdiprete,
Have you tried FlexASIO?

 

[John Mulcahy]

Distorted sweeps would be an output path issue rather than input.

 

[pdiprete]

Distorted sweeps would be an output path issue rather than input.

John:

Intuitively, that makes complete sense to me. The only interaction that I can imagine from what I've seen is that the ASIO4All control panel shows that the mics are sampling at the same rate as the output path (HDMI) when I set it explicitly at 48 KHz (I had it running clean one time at 96 KHz, but I did not check the output sample rate at that time). The bit depth in ASIO4All does NOT agree with windows -- I had the mics set at 24 bits for the last round of tests, but ASIO4All still reported 32 bits.

Output configuration is dead simple, right?

1. In windows, set the HDMI device to the desired sample rate and bit depth (48/24 in my tests)
   1. set "Spatial Audio" to 7.1 (in the case of the UMC-200, Atmos in the case of the 7703)
2. In ASIO4All, enable the device, so it can be seen by REW (NB: Sometimes this only shows up as the Intel Display Device, and others as the UMC-200 or 77003)
3. In REW, select 48 KHz sample rate to 48 KHz.

What did I miss?

 

[pdiprete]

John:

After uninstall / re-install of REW and ASIO4All, Java drives work fine proving the signal path.
ASIO4All fails in every configuration I've tried (I'll email or upload the full test results if that'll help).

This might be a hint though:

Note that ASIO4All is reporting to you 44.1/24, but the display device output is actually 48/24.
Nothing interesting in the log.

Forcing ASIO4ALL to resample to 48 KHz didn't help:

Is there a way to increase debugging, so we can see which sample rate / bit depth is being used, or do you think something else is going on?

 

[John Mulcahy]

The sample rate and sample form REW is using are shown at the bottom left of the main window. Note that the sample format the driver provides isn't necessarily the device format. As noted above, may be worth trying FlexASIO as an alternative ASIO wrapper. REW provides a control panel for FlexASIO if it is being used and generates the toml config file FlexASIO requires.

 

[pdiprete]

John:

Thanks for that, and apologies for not publishing my results from last nights' testing.

FlexASIO measures without distortion but is limited to a single mic. I have the upgrade, 4 UMIK-2 mics and a USB3 hub I'd like to engage. Is there a way to use FlexASIO with 4 USB mics?

I think I'm fighting an ASIO4ALL bug, and there are a few reasons why. Before loading this thread up with more detail, I want to do my testing and provide better details (or hopefully just solve the problem offline). In summary, a4info shows the correct information for the mics and display, but the ASIO4ALL control panel never agrees with reality.

In addition, as I test I ran the "generator" and put out a 1 kHz sine wave; clean as a whistle. As I stepped up by 1/3 octave (nice control, BTW), the tone was distorted at +1/3 and +2/3 octave but was perfect again at 2 kHz. So clearly, there's a disagreement in sampling rates.

I appreciate your sticking with this even though it's probably an issue w/ASIO4ALL.

 

[pdiprete]

The distortion issue is resolved.

The critical setting was "Allow Pull Mode," which shouldn't have been needed, but it works.
Even after setting that, I had to set the buffers pretty high (1024), which surprised me.
Resampling always came on by default, so I turned that off.
Weirdly, the screentip with the Device information was frequently wrong but hitting "reload" twice in the REW GUI usually corrected that.

If this continues to work, I'll see what I can offer regarding sorting / identifying mics before the weekend.