high end skew with 5.18, 5.19 beta, 5.19 release

D. Tester

Registered
Thread Starter
Joined
Aug 26, 2018
Messages
7
I’ve tried REW with some pro-audio interfaces and Mac OS (with java 1.8). But I am seeing inconsistent results in the high end frequency response form ~10K to 20K (top octave) depending upon the connection type. I will note that the loopback test for both interfaces show the interfaces frequency and phase response are ruler flat with only a slight phase shift below 5 Hz. and near the Nyquist frequency. Nothing changed during the sweep tests with anything positioned in the room, the room treatments, or the equipment used (other than the interface and connection to the machine). So neither the frequency response of the interfaces or the room setup would seem to account for a ~5 -15 dB difference in frequency response above 10K; it appears to be a function of how the interface is connected.

I started with a Mac running 10.12.6 with a Firewire 400 connection to a Metric Halo LIO8 interface. This yielded the flattest response from 10K to 20K and seems to be most consistent with how the room sounds and is treated. This is the relatively flat top green trace with the least amount of HF hash. There is nothing else using the FW buss.

The middle pink trace is with an Apogee Symphony I/O connected via its matching PCIe card (which provides a higher speed connection than FW). This is with Mac OS 10.11. But despite the lower latency, the high frequency response is skewed to be ~10 dB lower by the time it hits ~20K. REW recognizes the symphony hardware as both input and output devices.

The red trace is with the same Metric Halo LIO 8 but this time upgraded from the 2d card to the 3d card which replaces the Firewire 400 connection with a USB C connection and also audio over ethernet via a Mac driver. The USB C connection has by far the most HF skew and is down by ~20 dB at about 18K. This happens with Mac OS 10.12.6, or Mac OS 10.13.6. REW recognizes the USB C connection as both an input and output device. But REW recognizes the ethernet audio connection as a network audio device for output only; it does not recognize it as an input device. So I could not use REW with the ethernet connection. The pink and red traces were done at higher sampling rates, but in the end this made no difference.

I can understand that lower speed connections between the interface and the computer might cause timing issues with higher frequency data (for the same buffer sizes and data windowing setup). Or time skew for HF data might be the worst in the top octave. But these traces seem to show the opposite; the HF skew is worse for the faster connections and the slowest FW 400 connection has the flattest trace. So this makes me wonder if REW is not setup to work with high speed interfaces that use PCIe and USB C/USB 3.0 connections.

Finally, without knowing what the room sounds like, I don’t think it would be clear to the casual user what trace represents the true response of the room, i.e., there is no indication from REW that anything went wrong with running any of the 3 traces. Or if you did not have the opportunity to use different hardware connections, you might never question the plot of the top octave (BTW - it was easy to align the amplitude of all the traces in the overlay window at the lower frequencies where they match up).
 

Attachments

  • REW_top_octave_skew.png
    REW_top_octave_skew.png
    149.3 KB · Views: 13

John Mulcahy

REW Author
Joined
Apr 3, 2017
Messages
7,344
Best posting the mdat file for the measurements, the traces in the image look odd but really need to see the file to comment. The interface type shouldn't make any difference. The main contributors to odd results are monitoring/feedback - there must not be any path back from input to output - or using multiple sweeps when input and output are not on the same device. Multiple sweeps require precise sample clock alignment between input and output and are generally only suitable when input and output are on the same interface.
 

D. Tester

Registered
Thread Starter
Joined
Aug 26, 2018
Messages
7
Thank you John for the reply. I am attaching a .mdat.zip file with traces from the different hardware setups. I ran only single sweeps. The Metric Halo software console that controls the hardware does not allow you to create feedback loops. I set it up so analog 1,2 inputs and 1,2 outputs are available to REW. Happy to test any configurations you would care to suggest.
 

John Mulcahy

REW Author
Joined
Apr 3, 2017
Messages
7,344
Thanks. I've removed the cal files for ease of comparison, the soundcard cal was flat anyway and only two of the measurements used a mic cal file. Here are all 4 measurements with 1/48 smoothing applied. Two are with sub and two without, so the differences below 200 Hz can be ignored.

allspl.jpg


The green measurement (Symphony IO with Apogee PCIe) and orange measurement (Symphony IO with Lynx AES16e) are essentially identical, despite one being V5.18 at 48k and the other being V5.19 beta 12 at 96k. Both were measured on 1st September. The impulse responses look a little untidy, particularly the 96k measurement, reminiscent of OS resampling. Bear in mind that the sample rate used in REW should match the rate set up in the Mac's audio setup for the interface, otherwise the OS will resample between the two rates.

The red measurement (LIO 8 FW400) from 5th August has the cleanest impulse response and shows a little more high end. Mic alignment or positioning could account for that difference. The blue measurement (LIO 8 with USB C) from 23rd August has a less clean impulse response (though still better than the Symphony IO measurements) and some odd features happening late on in the impulse response, though they don't have any bearing on the bizarre high frequency drop.

To try and understand what might be going on I'd suggest making measurements of the different interface setups in a single sitting without moving the mic or altering the environment and making sure the interfaces are configured for the same sample rate as REW in all cases - perhaps 48k for the sake of simplicity. A possible cause of the HF dropoff for the LIO 8 USB C measurement could be increased latency in the measurement chain, resulting in the last part of the sweep not being captured. The easiest way to accommodate high latency is to use REW's acoustic timing reference option and to select the "Wait for timing reference" box on the Measure dialog, that will allow REW to remove any latency in the measurement chain.
 

D. Tester

Registered
Thread Starter
Joined
Aug 26, 2018
Messages
7
Thanks again John for reviewing the traces and the observations about the sample rate and impulse responses. You are right that the interfaces were sometimes set at 2X the sample rate set in REW. I have gotten better results now using the ethernet audio connection with the acoustic signal as the reference (with the wait option) - compared to the USB C connection. I am also going to check with the Metric Halo fto see if my LIO 8 mixer setup has introduced extra latency compared to when the box has the older hardware with the FW 400 connection.
 
Top Bottom