V5.20.14 early access build

[John Mulcahy]

Builds updated with these changes:

• Fixed: Window preset FDW widths were not restored properly on the next startup
• Fixed: Import sweep recordings could search too far into the data when looking for the first timing reference

 

[jtalden]

Yes, the impulse overlay button was used as circled in the second chart. measurements 1 and 2 are not selected there, but they changed also. It is the same action as if I selected 'Apply windows to all'.

 

[John Mulcahy]

I'm baffled then. I went through the same sequence you set out, using the "Apply to impulse overlay selections" button only changed measurements 3, 4 and 5, which were the ones I had selected there. No change to 1 or 2.

 

[John Mulcahy]

When exporting the impulse response as text, the "start time" in the impulse response file differs by 1.09ms
nearfield driver start time: -0.99978125 // Start time (seconds)
port output start time: -0.9986875 // Start time (seconds)

Is "start time" not t=0? Why should it differ by 1ms between these measurements? FWIW I have found similar results regardless of timing method used.

As an addendum to this, in case it isn't obvious: t=0 occurs (-start time) seconds after the start, the start time is relative to t=0. In samples that is (-start time)/(sample interval).

 

[jtalden]

Thanks, after another hour of testing I finally found my wits. Even though the button clearly indicates the selection on the overlay IR chart are the ones that are impacted, I was fixated that the current selection of overlay chart would be the selection - whether it be the All SPL, Phase Step, or any other overlay chart. I'm clear now. All is working as intended.

 

[KSTR]

@John Mulcahy
I'm experiencing problem with soundcard detection, under Linux (fresh Linux Mint install on Intel NUC).
REW (V5.20.14ea20) refuses to work with almost all USB soundcards I currently have at hand, the only working one is the RME ADI-2 Pro.

The soundcard lists fine and works with speaker-test:

speaker-test -D hw:USABRET -c 2 -F S24_3LE -r 96000

speaker-test 1.2.2

Playback device is hw:USABRET
Stream parameters are 96000Hz, S24_3LE, 2 channels
Using 16 octaves of pink noise
Rate set to 96000Hz (requested 96000Hz)
Buffer size range from 192 to 174762
Period size range from 96 to 87381
Using max buffer size 174760
Periods = 4
was set period_size = 43690
was set buffer_size = 174760
 0 - Front Left
 1 - Front Right
^C

The issue manifests exactly the same with two other USB DACs I'm currently testing.
EDIT: All of these use S24_3LE format, whereas the ADI-2 Pro is S32_LE

 

[John Mulcahy]

The message means REW asked the OS for an audio connection to the device and it was refused. @phofman had a comment on a similar issue that may be relevant: "Often these problems are caused by pulseaudio taking over the alsa devices. The best way is to disable all measurement devices in pulseaudio to leave them available to other processes through alsa."

 

[thothsong]

Something gone horribly wrong with today's 64-bit Windows build? Normally pretty much instant to load a file with 16 measurements, with the new build it's painting one about every 4 seconds, and each UI interaction is taking about that long.

 

[KSTR]

The message means REW asked the OS for an audio connection to the device and it was refused. @phofman had a comment on a similar issue that may be relevant: "Often these problems are caused by pulseaudio taking over the alsa devices. The best way is to disable all measurement devices in pulseaudio to leave them available to other processes through alsa."

No change when pulseaudio is disabled (actually: package removed).

The points is, why does speaker-test (part of alsa-utilties) work? It doesn't show "device busy" (like it would when another program has opened the device already).

I double checked with 5.20.13, no difference.

 

[thothsong]

I reinstalled 14ea19, and it works fine. Something's gone wrong with 14ea20, both with and without HW graphics acceleration.

 

[jtalden]

Yes, on my windows 10 PC the windows animalware service is laboring during both the loading of REW and the loading a large measurement file.

 

[John Mulcahy]

I have rebuilt them, please try the ea21 builds.

 

[thothsong]

Might even be a bit worse with ea21.

 

[John Mulcahy]

Very odd. I have reverted the build links to ea19, but I have no idea what is going on, I don't see any issue on my Win10 machine.

 

[jtalden]

Still seems the same to me, but I am having a very slow ISP connection. 'windows malware service' and 'windows compatibility connection' run at high levels when I opened task manager to see what was kicking the PC into high loads. I don't have any idea that this is only connected with REW. Everything has slowed down for me here lately, with my ISP problems. I just assumed this was only my issue until thothsong commented.

 

[thothsong]

I'm seeing Norton Security go CPU crazy with ea20 and ea21, but not with ea19. Norton isn't visibly complaining about anything, though.

 

[John Mulcahy]

Let's see if ea22 gets things back on track then. The changes compared to ea19 are:

• Added: Clarified IR window All SPL and impulse overlay button functions in tooltips
• Changed: the signal generator level field interprets entries ending in a letter that is a metric prefix as being a voltage figure, e.g. 10m will be interpreted as 10 mV
• Fixed: Window preset FDW widths were not restored properly on the next startup
• Fixed: Import sweep recordings could search too far into the data when looking for the first timing reference

 

[jtalden]

Normal speed now for me. Works fine. I also fixed my ISP problem just before testing this, so...

 

[thothsong]

Yep, ea22 is back to normal.

 

[thothsong]

Trying to take some measurements with ea22, UMIK-2, ASIO4ALL, and it almost always gets stuck forever in "Checking clock rate..." The log file at that point shows:
SEVERE: Exception null null
After I hit Cancel, the main window acts like it doesn't have focus, greyed out, can't interact with anything.

 

[John Mulcahy]

Please attach the rew_output.txt file. No need, I reproduced it.

 

[John Mulcahy]

Builds updated with these changes:

• Fixed: Array index out of bounds when measuring with acoustic timing reference
• Changed: Faster loading of measurements that have filter sets

 

[KSTR]

@John Mulcahy ,
any idea how to proceed with the issue from post #256?

Using a spare old laptop running an older Linux Mint I now could get the soundcards in question to work in REW (again with pulseaudio removed)... but the question remains, how come speaker-test and other alsa progs (like aplay) do work 100% correctly while REW is showing this strage error on the NUC machine (meaning the card is already occupied by another program)?
EDIT: Audacity does work as well.

A more verbose error log what exactly (which alsa library call) went wrong may help debugging the issue. Something like alsa call sequence similar to the sequence in https://github.com/alsa-project/alsa-utils/blob/master/speaker-test/speaker-test.c, function set_hwparams(), lines 429-543.

One thing I note that in REW we cannot specify direct hardware like one would do with speaker-test or aplay (hw:USABRET in this case), only USABRET [plughw:1,0] and USABRET [plughw:1,0] (which opens IMHO unwanted backdoors to hidden resampling).

 

[thothsong]

Fixed: Array index out of bounds when measuring with acoustic timing reference

Thanks, that fixed it. (Sorry I forgot about rew_output.txt.)

 

[John Mulcahy]

@John Mulcahy ,
any idea how to proceed with the issue from post #256?

Using a spare old laptop running an older Linux Mint I now could get the soundcards in question to work in REW (again with pulseaudio removed)... but the question remains, how come speaker-test and other alsa progs (like aplay) do work 100% correctly while REW is showing this strage error on the NUC machine (meaning the card is already occupied by another program)?
EDIT: Audacity does work as well.

A more verbose error log what exactly (which alsa library call) went wrong may help debugging the issue. Something like alsa call sequence similar to the sequence in https://github.com/alsa-project/alsa-utils/blob/master/speaker-test/speaker-test.c, function set_hwparams(), lines 429-543.

One thing I note that in REW we cannot specify direct hardware like one would do with speaker-test or aplay (hw:USABRET in this case), only USABRET [plughw:1,0] and USABRET [plughw:1,0] (which opens IMHO unwanted backdoors to hidden resampling).

There is no more information, unfortunately. The Java runtime is designed to isolate applications from the underlying hardware. Device access is handled by sound providers, which form part of the runtime. REW has no direct access to them, it can only ask the runtime's AudioSystem class what devices are available and try to connect to the selected device. In this case the answer from the underlying sound provider is no, but there is no information about why not. The most likely answer is that something else is using the device and it isn't allowing another connection, but it could also be that the sample rate or the format are not being accepted. REW asks the AudioSystem in advance for devices that can run at the current sample rate and uses formats the AudioSystem says the device can accept, but the answers to those questions can be yes, no or I don't know - the actual details of what connection a device will accept depend on the state it is in when you ask. @phofman may be able to offer more insight, he wrote the sound provider that gives access to ALSA PCM devices.