V5.20.10 Early Access

[John Mulcahy]

I tried the inversion trick with an RTA measurement, but could not get it to work. Should it work?

No, an RTA measurement doesn't have an impulse response. You could generate one by converting it to minimum phase, though I'm unsure how well that would work.

 

[ddude003]

Nice bit of work @John Mulcahy... The new trace arithmetic is pretty cool and seems to work well along the lines that you and @serko70 had outlined above... Thank you!!!

 

[John Mulcahy]

The new trace arithmetic is pretty cool and seems to work well along the lines that you and @serko70 had outlined above

Good to hear. I wasn't trying to provide an FIR generator, just tidying up the divide and inverse operations to include regularisation. Tacking on the frequency limits and notch exclusion were fairly simple additions. I don't think there is enough there to consider it a serious attempt at FIR EQ, but enough to play around with.

 

[ddude003]

After a few hours of "playing around" I have uploaded some room correction files to Roon that make my kit sound a bit better than anything I have tried before... Next up will be trying room correction via Audirvana+ LiquidSonics Reverberate with your trace arithmetic...

"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney...

 

[John Mulcahy]

One final set of updates have been made for the Windows and Linux versions of the early access builds. The big change is support for WASAPI exclusive when using the Java drivers, courtesy of some heroic work by Pavel Hofman. That means multichannel access and full sample resolution without any need for ASIO wrappers. The corresponding Linux AMD64 ALSA PCM support has also been updated. There are a few minor changes that I slipped in while working with Pavel on the WASAPI support:

• REW now retains the last 7 days of measurements in the temp folder, deleting any older than 7 days on startup. If REW did not shut down normally it will offer to load any measurements that were made since it last started up. If you mistakenly delete a measurement or forget to save it, there will be a copy in the temp folder of the REW log files folder for a week
• Added a soundcard preference to treat 32-bit sample formats as carrying 24-bit data, since formats that claim to be 32-bit almost always carry 24-bit data
• Allow a broader range for the speed of sound setting to accommodate media other than air
• Added check boxes in the FlexASIO control panel to select exclusive mode when using WASAPI
• Expanded the REW bit depth detector to 32 bits

A lot changed to accommodate WASAPI exclusive access, so feedback on how well that works (or doesn't!) is welcome. You may notice a slight delay after initial startup, depending on how many audio interfaces you have - WASAPI enumeration is a bit time-consuming since all possible format combinations have to be tested.

 

[thothsong]

The big change is support for WASAPI exclusive when using the Java drivers, courtesy of some heroic work by Pavel Hofman.

Wow! On a Windows box with no available input device, just wanting to test output generation, selecting any output device in Preferences causes this input error to pop up, is that to be expected?

 

[thothsong]

For the new Java WASAPI support, if the output device supports up to 8 channels, is there any way to configure REW to only output 5.1 instead?

 

[John Mulcahy]

Wow! On a Windows box with no available input device, just wanting to test output generation, selecting any output device in Preferences causes this input error to pop up, is that to be expected?

Yes.

 

[John Mulcahy]

For the new Java WASAPI support, if the output device supports up to 8 channels, is there any way to configure REW to only output 5.1 instead?

REW only outputs to one channel (or two if L+R is selected or a loopback reference is being used) so just select the channel you want to send the signal to. The interface determines which channels are available, not REW. There is an option to force only stereo output to be available if that box is selected on the soundcard preferences and the interface supports stereo (most do).

 

[John Mulcahy]

Wow! On a Windows box with no available input device, just wanting to test output generation, selecting any output device in Preferences causes this input error to pop up, is that to be expected?

You can stop that error message appearing by ticking the "Suppress soundcard errors" box on the View preferences, useful when running REW without an interface.

 

[thothsong]

REW only outputs to one channel (or two if L+R is selected or a loopback reference is being used) so just select the channel you want to send the signal to.

Yes, I understand that, but for analyzing sound system upmixing modes that process 5.1 and 7.1 content differently, it would be very useful to be able to output true 5.1. (Right now I manually construct 5.1 WAV files from REW-generated files.)

 

[thothsong]

You can stop that error message appearing by ticking the "Suppress soundcard errors" box on the View preferences, useful when running REW without an interface.

Ah, thanks!

 

[John Mulcahy]

Yes, I understand that, but for analyzing sound system upmixing modes that process 5.1 and 7.1 content differently, it would be very useful to be able to output true 5.1. (Right now I manually construct 5.1 WAV files from REW-generated files.)

REW is not generating content as such, it is sending audio data to the channels of an audio interface, so that doesn't really apply. Sending data to a selection of output channels is on the todo list, though.

 

[thothsong]

REW is not generating content as such, it is sending audio data to the channels of an audio interface, so that doesn't really apply.

In the case of HDMI output of LPCM, the channel count/configuration is significant. My sound system will process differently based on whether the incoming LPCM is stereo, 5.1, or 7.1. Having just the left channel active can produce different results in stereo, 5.1, and 7.1.

 

[thothsong]

I don't know if this is supposed to work, but using a UMIK-1 and Windows, within a single REW session, I start with Java WASAPI and take measurements that look good, then switch to ASIO4ALL and take measurements that look good, and then switch back to Java WASAPI and get corrupted measurements. Switching back to ASIO4ALL again looks good. Here's an example comparison between Java before and after:

 

[John Mulcahy]

Switching back and forth between Java and ASIO shouldn't cause a problem. If you get a bad measurement please open the Captured graph and look at the Captured trace to see if there are any dropouts in it, if so please capture an image of that.

 

[John Mulcahy]

I'm seeing occasions where the input signal drops below -90 dB, without any obvious cause, seems random. It will be a week or so before we can investigate further as Pavel is away.

 

[thothsong]

If you get a bad measurement please open the Captured graph and look at the Captured trace to see if there are any dropouts in it

Although it happened in both REW sessions I did yesterday, I've been unable to replicate the problem across multiple REW sessions today.

 

[thothsong]

Another odd Java output problem. With a UMIK-1, sometimes I swear I don't hear the initial timing chirp on the very first measurement of a session, nor do I see the blip of it in the Input display window, yet the measurement proceeds as if it occurred. I always hear the chirp in subsequent measurements. With a UMIK-2, each time I change the Sample rate between 48 kHz and 96 kHz within a session, the initial timing chirp on the next sweep is missing, and the measurement stays waiting for it. The trailing chirp then gets interpreted as the initial chirp.

 

[thothsong]

Oh, perhaps the missing first chirp is simply due to format switching time in my soundbar.

 

[thothsong]

Java with a UMIK-2 and HDMI output. Windows 10 shows the UMIK-2 support as:

and the HDMI output support as:

But if I try to select either 44.1 or 88.2 kHz Sample rate in REW, I get an error like this:

Happens even if I configure the Windows default for both devices to be 24-bit 44.1 kHz.

 

[John Mulcahy]

Shared mode can support almost anything as Windows will do the conversions. When you select a WASAPI exclusive device in REW the sample rate selector is updated with the sample rates the device supports, but the rates may also depend on the channel selections. If you use the Generate debug file button on the Soundcard preferences you can see the list of formats each interface supports.

 

[thothsong]

If you use the Generate debug file button on the Soundcard preferences you can see the list of formats each interface supports.

Debug file attached, which shows that the interface supports it.

 

[John Mulcahy]

Debug file attached, which shows that the interface supports it.

It does, but it is the device which refuses to provide a line, not REW. Perhaps there are some other conditions (processing mode?) for it to run at 44.1 kHz/8-ch over that interface.

 

[thothsong]

Perhaps there are some other conditions (processing mode?) for it to run at 44.1 kHz/8-ch over that interface.

The HDMI EDID is constant, it doesn't vary with sound processing mode. The EDID advertises 16/20/24-bit at all HDMI-supported sampling rates, up to 8 channels. It's advertised in a single Short Audio Descriptor, which means it isn't even possible to express that 8-channel 44.1 kHz is not supported but 8-channel 48 kHz is. I can configure Windows for 7.1 24-bit 44.1 kHz output, and play a 7.1 32-bit 44.1 kHz WAV file, and have verified that the output coming from the PC is in fact 7.1 24-bit 44.1 kHz LPCM. I get the same error on a second PC, using a different HDMI driver/interface.