Discrepancies after version update

[BrechtDeMan]

Couldn't find this issue on here but apologies if I missed something obvious.

Had been using v5.10 for a while, then downloaded v5.20 the other day. Every measurement with this version is weird, the spectrogram shows it nicely but of course this dramatically affects the other "views" too.

V5.10:

V5.20, repeat measurement with identical setup and parameters as far as I can tell:

Kindly let me know what other info is useful to troubleshoot this.

As an aside, is there a way to make the .mdat open in earlier versions?

Thanks!

 

[John Mulcahy]

Probably best to attach the two mdat files. The mdat files are not backwards compatible, but the impulse response could be exported as a WAV file and imported in an earlier version.

 

[BrechtDeMan]

Thanks John!

See attached, "oldgood.mdat" and "newbad.mdat".

 

[John Mulcahy]

Strange looking impulse response for the new measurement, with a lot of noise. The left IR window is set very large on the new measurement for some reason.

There is limited information in the files (no volume control settings, for example) because you have not selected the input device, input, output device or output. Please make those selections. Please also use a single 256k sweep and make sure the devices you are using for input and output are configured in Audio Midi setup to use the same sample rate as you have selected in REW.

 

[BrechtDeMan]

Attached: Measurement with input/output and devices explicitly specified, and single 256k sweep. Sample rates are set to 48 kHz throughout.

Old version:

New version:

Thanks again.

 

[John Mulcahy]

Strange. What devices are being fed through the Dante Virtual Soundcard? What is the Dante latency set to? Higher is probably better.

After you make a measurement with 5.20 go to the Captured graph and check that the captured sweep has not been truncated in some way and that there are no gaps in it. That graph only has data for the last measurement made, so needs to be checked before making another. After that try making a measurement with the Acoustic timing reference selected on the Measure dialog, with the ref output set the same as the measurement output. If there is some capture alignment problem that should deal with it.

 

[BrechtDeMan]

Huh! Thanks for the help, based on the captured graph I'd say it's probably similar to this issue: https://forum.audacityteam.org/viewtopic.php?t=101564

As you suggested there are gaps in it - LOTS. Recordings via the Dante Virtual Soundcard sound "chopped up" / stuttering in Audacity, and apparently also in this version of REW. Other applications are fine for me, so it took me a little while to figure out.

Of course I could use the old version, or a different audio interface, but it would be really convenient if I could use this great piece of software AND my built-in setup... Curious if it's fixable.

To your questions:
- Focusrite Pro Rednet 4 and 2 for the I/O (this is a project studio live room)
- 10ms latency, which is the maximum
- Dante Virtual Soundcard may not be ideal here, but a (low latency) hardware solution is not an option right now
- I played around with the acoustic reference and input/output device buffer size, and the acoustic reference markedly improved on the issues when the buffer size is very high (256k)

 

[John Mulcahy]

That does look a little difficult to handle!

The gaps are so regular I wonder if there might be some format issue, could be worth trying other formats offered for the DVS input in Audio Midi Setup, if there are any choices. Why it works in 5.10 and not now is something of a mystery.

The interface requirements for audio measurement are very modest, no need for a high performance soundcard - built-in audio is usually more than good enough. Appreciate that may not be practical for your setup though.

 

[John Mulcahy]

I have put a test version here which might behave differently. It only has a small change to a flag that may affect audio behaviour, but worth trying to see if it helps.

 

[BrechtDeMan]

Wow, thanks very much for that John. Unfortunately the issue seems to persist.
I've tested various sample rates and encodings (bit depth). The "chopper" rate goes up with sample rate, so no doubt you're right it's something to do with the encoding.

I'll do more testing and asking around too...

 

[John Mulcahy]

Came across this, not sure if it is relevant.

With such regular gaps I wonder if there is some issue with the channel configuration, leading to data in the stream being allocated to the wrong channel. It may be worth trying different DVS input channel configurations/different numbers of channels.

 

[John Mulcahy]

Have you tried any versions between 5.10 and 5.20 to see if any of those work? 5.19, for example? Knowing when it stops working might help narrow down what might be going on.