Possibility to have a Burst Decay option

[Jimmy Venema]

I build speakers as a hobby and use REW as measurement tool and I'm very happy with it, but still have an improvement request.
A common practice to verify if there are no naste resonances from your cabinet is to have a look at a Burst Decay graph. It looks very similar to the waterfall graph, it is also 3D like, but the difference is the time axis. Instead of having the time, this axis now represents the number of cycles at that frequency. Thus "10" at 1 kHz is effectively 10 ms, but would be 1 ms at 10 kHz.
For a loudspeaker cabinet it is important that within a number of cycles the level is decayed below a certain level. Thus it is essentially the waterfall with the time axis represented slightly different. I think many hobby speaker builders would be very happy with this feature. I know that the origin of the program is targeted at room accoustics and the improvement of it, but I know that the program is also very popular in the speaker builder community.

 

[John Mulcahy]

Burst decay is on the todo list somewhere. There is a little more to it than changing the time axis, however.

 

[Jimmy Venema]

As usual there is no free lunch! Glad to hear it is on the todo list.

I further notice that sometimes a measurement goes totally bogus. Then you just throw the last measurement away, redo it and then it is normally ok. Is it possible that during a measurement the garbage collector kicks in and the measurement goes wrong because of that? I noticed that the longer you use REW and the more measurements you do, the higher the change of having this problem. A fresh restart of REW keeps the problem away for a while. If the garbage collector is the issue, is it an idea, to force its invocation just before you actually do a new measurement?

In my professional life I'm a C++ programmer, but colleagues did use garbage collector languages like C# and we did have our share of issues because of the garbage collector kicking in at critical moments.

 

[John Mulcahy]

There is a call to System.gc() at the end of every measurement, but I can add one when the Measure dialog is displayed. If you get a bad measurement worth looking at the Capture graph to see if there were dropouts in the captured sweep.

 

[Jimmy Venema]

I normally throw those measurements away immediately. But I can describe how it looks like then. The real time display in the measurement dialog (bottom left) then shows sharp dropouts. Thus the green/yellow/(red) stuff is then gone for about 3 mm on my display (goes down sharp en then sharp back). Then there is signal for 4-5 mm then it is gone etc. Normally the sweep sound I hear is still ok. But sometimes also the sound is effected, but that occurs less then an input interruption.

The most important time critical thing REW does, is as I can see the measurement. It will also produce a bulk of data, so I can understand that you do a call right after it to tidy things up. But If you play with gate windows and change time ref, play in "All SPL & Impedance" with the selection etc, there is perhaps also a memory use/impact and thus perhaps if you do a measurement, then the garbage collector can perhaps kick in at that moment you will not want. Is it possible to block the possibility to have a garbage collection during the short period of time a measurement is buzy. More like an enter and a leave with critical sections mutex? It is also a situation that you do not want other threads to interfere in case it is a multi threaded application.

 

[John Mulcahy]

What OS are you on? Can't say I've personally ever seen dropouts during measurement, even at 768 kHz (with ASIO).

 

[Jimmy Venema]

MacOS, but it kicks in after say 20 measurements or so. Thus that's why I suspect the garbage collector as the culprit. If it is the the GC, then the sample rate is not really of importance. Then the question is if the GC does something during the sweep of say 20 seconds. The way it works is that it just stops all threads for a while and then does it's collect thing. At least for a full scan, since that can move objects in memory. The first generation scan is less demanding, it just searches if the objects allocated since the previous scan are still in use or not. That just makes gaps in the memory and there is no need to stop the other (working) threads.
I've seen projects with serious GC problems that worked around it. That application was very dynamic in memory use, but only for a very limited number of object types. It was solved, by never releasing those types of objects, but putting them in a "free" list. Thus the GC only had to work on a very limited set of objects. As a result during a full scan there are hardly any objects found that can be released, so there are almost no gaps thus the compaction which is the hard part that needs a full stop is very short in time. Plus "new" objects from the free list are way back in the "old" memory segment. New objects of the few special types will never end up in the young memory segment. Thus the young generation scan is also more effective.
Note that in the environment I worked in it was very common to have hundreds of megabyte of objects in memory and it was also very dynamic in behaviour, thus many changes. And with a usage pattern that almost nothing will be found in the young object first generation scan thus almost everything has to be found in the expensive full scan. And with those in core memory size and a lot of compaction work a full scan could block the application for multiple seconds, which was unacceptable. Connections would timeout etc, A reconnection often forced some resend of information, that would result in a full GC and the system would more or less bring itself to a halt.
So there are cases GC is a blessing, but there are also cases that it is challenging to put it mildly.

 

[John Mulcahy]

I understand the operation of the GC, I just haven't encountered the behaviour you describe in what is now more than 15 years of developing the application. Java's default GC works well. I do the macOS builds and tests on a late 2012 i5 mac mini, to make sure the app continues to run as expected on what is by modern standards pretty modest hardware. I just ran 50 measurements in a row, generating a spectrogram after each since that is about the most memory-intensive operation, running hundreds of FFTs, and all were fine. I wouldn't assume GC is a factor in what you are seeing, but the heap usage is shown in the bottom left corner of the main window if you want to keep an eye on it. If REW were to get swapped out that could cause issues, but would be unusual unless the machine had other heavy demands on memory. Java processes do not run at high priority, so it is also fairly easy for other activity on a machine to intrude. Heavy file system I/O by other applications could also cause problems. As with any audio application it is best to make sure the machine isn't doing much else.

 

[Jimmy Venema]

I often also have a windows session running via parallels, because other software I use like VituixCad, Rehase and SigmaStudio are windows only. It is not that I actively use those windows applications while using REW, but it is always possible that just the fact that windows is running in parallels has a bad influence. The scheduler in MacOs is in my opinion beter as the scheduler in windows, but having windows running in a VM could always have strange side effects. I will keep an eye on it and keep track if there is a correlation with windows also running.

 

[Jimmy Venema]

I see 341/636MB in the bottom left corner, but the strange thing is, the first number is growing it started at about 300 and grow to 350, then it went back to 300/513MB. Why does it grow while the program isn't used? now it is at 310/624.

 

[Jimmy Venema]

Sorry my bad! I'm used to non CG, then the memory is a flatliner if you do not use an application. I guess here the message pump gets moving the memory pointer forward. Eventy time a new object is put in the message pump. In my C++ case experience after the message is ready, it is deleted and reused a next time a message is put in the message pump. Thus then essentially the memory footprint remains stable. Now with a graphic application and thus a message pump that is always doing something and the memory footprint is always growing, till the cheap first generation scan will reclaim it all.

 

[John Mulcahy]

Yes, on Java the Event Dispatch Thread handles all the UI activity and will be processing mouse events, UI redraws etc all the time the app is open.

 

[teyhyrh4r]

now that it is included, is there any use for room meassurements, too?