REW Beta Release The RTA function slows down on REW version 5.20 beta 53 on Raspberry Pi

[Antonio Di Motta]

In this latest beta 53 I have experienced a significant slowdown of the RTA function also using a raspberry Pi 4 set to the CPU frequency of 1.75Ghz.
The RTA function stops for a few moments and after a while it regularly resumes, this problem was not evident in the beta 52 version.
Thanks for the attention.

 

[John Mulcahy]

Can you tell me anything more Antonio, that's a pretty sparse report. What are the RTA settings? Does FFT length make a difference? Were you measuring distortion? Was averaging being used? What was the sample rate? What were the axis settings?

 

[Antonio Di Motta]

John, I apologize for being superficial in describing the problem, but at the time I couldn't describe the details.
Now I'm working with a sound card that samples at 192Khz and with an input and output buffer of 32Kb, REW generates a frequency of 1Khz and simultaneously performs the RTA function with the parameters that I send you in the attachment. Even when I resize the RTA window it almost always takes a long time to update the graphics even when the recording is turned off. Attached I also send you a video of how the RTA function behaves so you can evaluate the update time of the graph.
Rename the file VID_20200529_181000_new.txt to VID_20200529_181000_new.mp4
Thanks

 

[Antonio Di Motta]

I tried to change the input buffer and bring it to 64Kb but there are no great improvements, the presentation is always not very fluid and often freezes for 1-2 seconds and then resumes. If I decrease the sampling frequency to 96Khz the updating of the graph is slower but more fluid.

 

[John Mulcahy]

I get between 4 and 5% CPU for the same settings at 192 kHz on my Win10 system, and the same for beta 52. Does beta 52 behave differently for you? Could anything have changed on the graphics driver or OpenGL selection?

 

[Antonio Di Motta]

In fact I have to try again with version 52 because I don't remember if I had set the sampling frequency to 192Khz. On the Raspberry the percentage of CPU goes from a minimum of 30% to 35-40%.
But the thing I don't understand is because at 192Khz the updating of the graph is much faster than at 96Khz.

 

[John Mulcahy]

Of course, it takes half the time to accumulate the samples required for the FFT.

 

[Antonio Di Motta]

I hadn't thought about it, my reasoning was different because I thought that having a higher sampling frequency the useful spectrum increased and consequently the system had to slow down.
So if I increase the input buffer to 64Kb the update time should be the same as the 96Khz sampling frequency with 32Kb buffer input?

 

[John Mulcahy]

The buffer shouldn't make any difference, for faster update increase the overlap, that and the FFT length determine how many samples are needed for the next FFT to run.

 

[Antonio Di Motta]

In fact, the update does not depend on the amount of the input buffer. But I noticed that increasing the buffer the update seems slightly more fluid.

 

[Antonio Di Motta]

I installed version 52 and this too is not very fluid at 192Khz but after about a minute from the RTA of RTA it becomes fluid and rarely slows down. With versionr 53 it seemed much worse. Now try again with version 53.

 

[Antonio Di Motta]

Version 53 takes much longer to stabilize and in any case always tends to have a less fluid coportation than version 52.

 

[John Mulcahy]

I don't have any explanation for the difference Antonio, beta 53 added coherent averaging but it is only used when selected and measuring distortion, and you are not doing either.

 

[Antonio Di Motta]

Hi John, I did several tests between version 52 and 53 and in fact there seems to be no difference in behavior, both as soon as you start the RTA function they update the graph with discontinuity then with the passage of time it becomes much more fluid. It seemed to me that version 52 was faster to recover this fluidity but it is difficult to evaluate it. I then confused the size of the input buffer and the length of the sample that is passed to the FFT function, effectively increasing this length the weighting slows down a lot due to the limited processing power of the Raspberry Pi 4.
I noticed, however, that the CPU is much more busy when the darkness is set to 32K compared to higher values of 64K and 128K, as if to indicate that graphics processing is heavier than the FFT function.

 

[Antonio Di Motta]

Since increasing the length of the samples also increases the resolution of the graph, it would perhaps be interesting to display this parameter on the RTA graph.

 

[Antonio Di Motta]

I did other tests including the use of the 64 bit linux kernel and a higher system clock at 1750Mhz for the CPU and 650Mhz for the GPU improving the situation only slightly. I did a test with the 3.0 analyzer that uses the first version of the Raspberry Pi3 with the stable version of REW the 5.19 with java virtual machine version 1.7 and although it is much slower it does not present this instability of the refresh rate of the graph.
I would not like the problem to be related to the java virtual machine 1.8 which optimizes the execution of the code with the passage of time and which initially is slower and more unstable and then recovers fluidity. Now I am trying to install a 64bit operating system and a 64 java virtual machine on the raspberry Pi 4 to understand if I can eliminate this annoying behavior.
Thanks for the attention ...

 

[Antonio Di Motta]

This is a short video that shows how the RTA function on Raspberry Pi 3 with Xubuntu operating system version 16.04 32bit and Java virtual machine version 1.7 behaves. As you can see, the update is not very fast but very fluid, while in the video with the latest version of REW the 5.20 beta 53 despite the decidedly more performing hardware is much faster but decidedly discontinuous at the start of the boot dela RTA function.
Attached is the video to be renamed to .mp4.

 

[Antonio Di Motta]

John, I made a clean installation of Raspberry OS 64bit and I also installed the 64 bit virtual machine oracle, when I install REW it appears to me only in text mode and after REW it doesn't run.

Linux raspberrypi 5.4.42-v8+ #1319 SMP PREEMPT Wed May 20 14:18:56 BST 2020 aarch64 GNU/Linux

java version "1.8.0_251"
Java(TM) SE Runtime Environment (build 1.8.0_251-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed mode)

Error:
pi@raspberrypi:~/REW $ ./roomeqwizard
giu 11, 2020 7:20:41 PM roomeqwizard.RoomEQ_Wizard A
GRAVE: Error during startup java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
at roomeqwizard.RoomEQ_Wizard.main(y:727)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.exe4j.runtime.LauncherEngine.launch(LauncherEngine.java:84)
at com.install4j.runtime.launcher.UnixLauncher.start(UnixLauncher.java:66)
at install4j.roomeqwizard.RoomEQ_Wizard.main(Unknown Source)
Caused by: java.awt.HeadlessException
at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:204)
at java.awt.Window.<init>(Window.java:536)
at java.awt.Frame.<init>(Frame.java:420)
at java.awt.Frame.<init>(Frame.java:385)
at javax.swing.SwingUtilities$SharedOwnerFrame.<init>(SwingUtilities.java:1763)
at javax.swing.SwingUtilities.getSharedOwnerFrame(SwingUtilities.java:1838)
at javax.swing.JWindow.<init>(JWindow.java:187)
at javax.swing.JWindow.<init>(JWindow.java:139)
at roomeqwizard.rA.<init>(y:1194)
at roomeqwizard.RoomEQ_Wizard$1.run(y:2165)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

giu 11, 2020 7:20:41 PM roomeqwizard.RoomEQ_Wizard A
GRAVE: Error cause: null
java.awt.HeadlessException
at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:204)
at java.awt.Window.<init>(Window.java:536)
at java.awt.Frame.<init>(Frame.java:420)
at java.awt.Frame.<init>(Frame.java:385)
at javax.swing.SwingUtilities$SharedOwnerFrame.<init>(SwingUtilities.java:1763)
at javax.swing.SwingUtilities.getSharedOwnerFrame(SwingUtilities.java:1838)
at javax.swing.JWindow.<init>(JWindow.java:187)
at javax.swing.JWindow.<init>(JWindow.java:139)
at roomeqwizard.rA.<init>(y:1194)
at roomeqwizard.RoomEQ_Wizard$1.run(y:2165)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)


Could you give me a tip Thanks

 

[John Mulcahy]

It looks like you have installed a headless runtime, one that is configured to operate without a display, keyboard or mouse.

 

[Antonio Di Motta]

Strange, I installed the 64-bit virtual machine in the same way I install the 32-bit version without any problems. The graphics were already missing during REW installation, in fact I made the choices in text mode. Maybe it could be due to the fact that this version of the operating system is still a beta and that something is missing for the correct functioning. I try to install the 32bit virtual machine on the 64bit operating system and if it doesn't work it could certainly depend on the operating system.

 

[Antonio Di Motta]

I noticed that between the setting of the RTA function there is the Max Overlap parameter. As you increase the value, updating the graph speeds up and the workload on the CPU of the java process increases considerably. It goes from 10% CPU load with the setting at 50 to 30-40% with the value set at 93.75.
What does this Max Overlap parameter do?
Thanks John ...

 

[John Mulcahy]

From the help:

Max Overlap
The spectrum/RTA plot can be updated for every block of audio data that is captured from the input, overlapping sequences of the chosen FFT length. This can present a significant processor load for large FFT lengths. The processor loading can be reduced by limiting the overlap allowed using this control.

To expand on that, each FFT requires the number of samples in the FFT length. If max overlap is zero. REW will wait after generating an FFT until another FFT length set of samples has been received, then run the FFT again. If the overlap is 50% it will run the FFT after half of FFT length samples have been received, using the last half of the samples from the previous FFT plus the new samples. The more overlap is increased, the fewer new samples are required to trigger a new FFT so the more often FFTs happen.

There is also an Update interval setting in the Appearance controls, if that is increased from 1 the graph will only be updated at the chosen interval though FFTs will still be calculated per the chosen overlap.

 

[Antonio Di Motta]

I should have seen in the help before disturbing you, I'm sorry I'll try to be more careful before posting questions to which there are already answers.

Thanks

 

[John Mulcahy]

That's no problem Antonio, I'm sure others have had the same question.

 

[Antonio Di Motta]

Oracle Java 8 32 bit and 64 bit are incompatible with the 64bit Raspberry OS operating system. Installing the default version of OpenJDK 11 REW doesn't work and so I had to install OpenJDK 8 64bit from an unofficial repository. With this version REW works well and magically that problem of lack of fluidity of the graph update of the RTA function has disappeared. I have also tried with 1M FFT sample length and blocking does not occur with the OS and java 32bit version.
I keep testing to verify that everything is working properly, finally the Raspberry-based system continues to work well !!!