Room response recording with Timing Reference

[Pano]

I'd be happy to run some sweeps using 2 interfaces and post the MDAT files somewhere.

 

[seashell]

I'll correct some misinformation I posted. I was going off of REW's author's statement in the ASR thread that the timing drift offset was too big of a change to add to 5.20 and it would wait until 5.21. It appears he changed his mind though as it is an option now in the 5.20 beta / pre-release.

 

[phofman]

REW sucks great time under Linux (Fedora) though. E.g windows just won't refresh from time to time. It's really bumpy.

Did you enable the OpenGL option at install time?

IME REW requires fast graphics, fast response of the UI layer. Generally linux graphics is slower than on windows (Xwindow is a VERY complicated protocol because of the historical features, e.g. full network support etc.). That it the very reason for Wayland which still has a long way to completion. Running REW on linux over teamviewer (sort of VNC) increases glitches frequency in long FFTs, even though it has nothing to do with audio processing or java speed. IMO response from the windowing layer just gets slower, making some key threads in REW not being able to keep up with the audio stream from javasound.


REW is just a pure java application, it cares very little about the actual platform (some minor checks for defaults, etc.). What java8 do you use? Most likely OpenJDK, but Oracle did have ARM build too Install Oracle Java 8 on Debian Jessie and Raspbian Jessie .

It may be worth trying the latest openjdk java on RPi, perhaps the UI integration has been improved. REW runs fine on latest java in linux, it just requires downloading a jar with modules which have been removed from JRE in java9 https://www.diyaudio.com/forums/sof...stortion-measurements-rew-32.html#post6130483 . REW has been "stuck" at java8 (for very good reasons) but it will have to move on to new java versions eventually.

 

[seashell]

Doing a quick check of the FR of the sweep/inverse pair generated by the python scripts anyone using them might want to increase the end tapering. There's more ringing than necessary.

Attached plot shows start and end of FR of a 10 second chirp/inverse generated using the scripts (top) and a 10 second chirp/inverse generated using glsweep from DRC-FIR (bottom). Amusingly I also noticed the inverse chirp from glsweep actually has an off by one error in it but it's of no practical impact.

 

[soundcheck]

Here's my first test IR using REW and timing references.

The test is done with my nearfield desktop Adam A5X rpi4+iFi DAC as client.

I doesn't seem to look messed up like the IRs I've seen with the drift not being taken care of.


Does it make sense? What is this graph telling me? ( A huge reflection of the table surface!?!?)

Thx.

 

[soundcheck]

Did you enable the OpenGL option at install time?

IME REW requires fast graphics, fast response of the UI layer. Generally linux graphics is slower than on windows (Xwindow is a VERY complicated protocol because of the historical features, e.g. full network support etc.). That it the very reason for Wayland which still has a long way to completion. Running REW on linux over teamviewer (sort of VNC) increases glitches frequency in long FFTs, even though it has nothing to do with audio processing or java speed. IMO response from the windowing layer just gets slower, making some key threads in REW not being able to keep up with the audio stream from javasound.


REW is just a pure java application, it cares very little about the actual platform (some minor checks for defaults, etc.). What java8 do you use? Most likely OpenJDK, but Oracle did have ARM build too Install Oracle Java 8 on Debian Jessie and Raspbian Jessie .

It may be worth trying the latest openjdk java on RPi, perhaps the UI integration has been improved. REW runs fine on latest java in linux, it just requires downloading a jar with modules which have been removed from JRE in java9 https://www.diyaudio.com/forums/sof...stortion-measurements-rew-32.html#post6130483 . REW has been "stuck" at java8 (for very good reasons) but it will have to move on to new java versions eventually.

I am running it on my workhorse NUC i5 and Fedora32 which uses Wayland.

java -version
openjdk version "1.8.0_265"
OpenJDK Runtime Environment (build 1.8.0_265-b01)
OpenJDK 64-Bit Server VM (build 25.265-b01, mixed mode)

 

[fluid]

Does it make sense? What is this graph telling me? ( A huge reflection of the table surface!?!?)

Thx.

The first millisecond is the speaker settling or extremely close surfaces interacting, the first obvious reflection is at 2.3ms which is still very early. The view is highly zoomed in. Also have a look at the step response as that will give you a better indication of the time performance of your speaker. The IR is dominated by high frequencies and it obscures a lot.

Another thing to check is to apply a 15 cycle FDW through the IR windows tab. Then go into impulse and press the clock adjust (don't adjust it) and have a look at the phase graph. If the phase trends back down to zero near the nyquist frequency then that is a good indication things are OK. If the phase is still messy then use a lower cycle count.

 

[phofman]

I am running it on my workhorse NUC i5 and Fedora32 which uses Wayland.

I have no experience with ancient java 8 over super new and WIP wayland but would expect a pretty rough ride.