UMIK-2 SPL issue

ata5

Registered
Thread Starter
Joined
Mar 21, 2021
Posts
6
Hello,

When I load the UMIK-2 calibration file into REW, the SPL is not displayed correctly.
This SPL is very different from my SPL meter.
If I set the UMIK-2 volume to the same value as the “Sens Factor” (-12.7dB with my UMIK-2) instead of 0dB, it matches.
It seems that REW is ignoring the "Sens Factor". How do I set it so that the correct SPL is displayed when the UMIK-2 volume is at 0dB?
My OS is "Windows10 Pro 22H2".
 

Attachments

  • 01.PNG
    01.PNG
    176.6 KB · Views: 10
  • 02.PNG
    02.PNG
    171.1 KB · Views: 14
  • 03.PNG
    03.PNG
    135.3 KB · Views: 8
  • 04.PNG
    04.PNG
    147.1 KB · Views: 11
  • 05.PNG
    05.PNG
    149.7 KB · Views: 9
  • 06.PNG
    06.PNG
    179.5 KB · Views: 13
  • 07.PNG
    07.PNG
    183.3 KB · Views: 11
Last edited:

John Mulcahy

REW Author
Joined
Apr 3, 2017
Posts
8,148
Is there no option besides "Default input" for the UMIK-2 input? REW needs to access the actual input to be able to read the volume control setting and apply the sens factor.
 

ata5

Registered
Thread Starter
Joined
Mar 21, 2021
Posts
6
Thank you for your reply.
When “EXCL: UMIK-2” is selected as input device, only “Default Input” is displayed.
In shared mode, “LINE_IN” is displayed.
 

Attachments

  • UMIK-2 Input1.PNG
    UMIK-2 Input1.PNG
    43.2 KB · Views: 17
  • UMIK-2 Input2.PNG
    UMIK-2 Input2.PNG
    43.9 KB · Views: 16

John Mulcahy

REW Author
Joined
Apr 3, 2017
Posts
8,148
That's odd, would normally expect something like this:

1717406647123.png


The problem may be the truncated input device name in shared mode, ending "(UM" instead of "(UMIK-2)". REW needs to match the list of inputs to the input device name, and in EXCL mode the inputs list comes from the shared mode device entry. In this case the entries don't have matching names so the inputs aren't found. I don't know why the shared mode device name is truncated. Can you use the option in the Help menu to "Generate diagnostic file" and attach that, please?
 

ata5

Registered
Thread Starter
Joined
Mar 21, 2021
Posts
6
Indeed, the device name is strange in shared mode.
I have attached the diagnostic information.
I am using Japanese Windows and the area marked in red in the attached image is garbled.
Is this partly due to the fact that there are 2-byte characters in the device name, etc.?
 

Attachments

  • Garbled characters.PNG
    Garbled characters.PNG
    43 KB · Views: 15
  • REWdiagnostic_1717413869278.zip
    33.7 KB · Views: 9

John Mulcahy

REW Author
Joined
Apr 3, 2017
Posts
8,148
This problem with Japanese fonts came up before, in 2020. There is a bug in the Windows Java runtime native code for audio devices which transfers the bytes of the device names in the default character set of the machine, but the Java code is expecting UTF-8 data. I have a workaround in my code which tries to correct the strings, but it is possible for the incorrect data to also be cut short, so my code doesn't get the whole string and can't properly fix it. I can't work around that, unfortunately.
 

andyc56

Member
Joined
Jun 2, 2017
Posts
42
This problem with Japanese fonts came up before, in 2020. There is a bug in the Windows Java runtime native code for audio devices which transfers the bytes of the device names in the default character set of the machine, but the Java code is expecting UTF-8 data. I have a workaround in my code which tries to correct the strings, but it is possible for the incorrect data to also be cut short, so my code doesn't get the whole string and can't properly fix it. I can't work around that, unfortunately.
Is this something that using the MS Beta feature of setting the Windows active system code page to UTF-8 might help with?
 

ata5

Registered
Thread Starter
Joined
Mar 21, 2021
Posts
6
This problem with Japanese fonts came up before, in 2020. There is a bug in the Windows Java runtime native code for audio devices which transfers the bytes of the device names in the default character set of the machine, but the Java code is expecting UTF-8 data. I have a workaround in my code which tries to correct the strings, but it is possible for the incorrect data to also be cut short, so my code doesn't get the whole string and can't properly fix it. I can't work around that, unfortunately.
Thank you for the detailed explanation. It is unfortunate that there is no workaround.
I have a few questions.

* Is it correct to assume that the measurement results are the same when REW successfully obtains the device name and applies the "Sens Factor", or when the "Sens Factor" is not applied and the volume of UMIK-2 is adjusted by the Windows mixer?

* Is it possible to implement a feature that lists the device names that did not match in shared mode and EXCL mode and manually match them?
For example, I can set "EXCL: LINE (UMIK-2)" and "LINE (UM)" to "Group 1" on the REW side, forcing it to recognize that they are the same device.
 
Last edited:

John Mulcahy

REW Author
Joined
Apr 3, 2017
Posts
8,148
Is it correct to assume that the measurement results are the same when REW successfully obtains the device name and applies the "Sens Factor", or when the "Sens Factor" is not applied and the volume of UMIK-2 is adjusted by the Windows mixer?
The sensitivity information has no effect on the shape of the graphs, just the position of the SPL axis.

Is it possible to implement a feature that lists the device names that did not match in shared mode and EXCL mode and manually match them?
For example, I can set "EXCL: LINE (UMIK-2)" and "LINE (UM)" to "Group 1" on the REW side, forcing it to recognize that they are the same device.
That doesn't seem practical.
 

ata5

Registered
Thread Starter
Joined
Mar 21, 2021
Posts
6
Is there any chance that the developers of Windows Java Runtime will fix this bug?

Also, is there any other way to match the SPL axis other than the following?

* Turn down the volume of the UMIK-2 with the Windows audio mixer
* Set an offset to the measurement results
* Set the Windows system code to UTF-8
 

John Mulcahy

REW Author
Joined
Apr 3, 2017
Posts
8,148
Is there any chance that the developers of Windows Java Runtime will fix this bug?
There's always a chance, but it has been years since I reported that to them.

Also, is there any other way to match the SPL axis other than the following?
You could add an offset to the cal file frequency response figures. Import the file in Excel, add the offset, export it again.
 

ata5

Registered
Thread Starter
Joined
Mar 21, 2021
Posts
6
There's always a chance, but it has been years since I reported that to them.
Indeed...after 4 years, the bugs haven't been fixed...

You could add an offset to the cal file frequency response figures. Import the file in Excel, add the offset, export it again.
I hadn't thought of that method! Thank you very much.

The REW you have developed is a great software.
I tried to make a small donation with Paypal, but I got an error saying that donations from Japan are not supported.
If you could send me your payment email address, I would like to small donate.
 
Top Bottom