REW Beta Release REW API beta releases

Thanks again, John! Using Java solved the crackling problem.
However, I haven't been able to find a way to play two channels simultaneously, aside from the available L+R preset.
So, with Java, there's no option to select a secondary output like with ASIO? Isn't it possible, for example, to sweep with both surrounds simultaneously, rather than Center plus LFE?
Ettore
 
There's an option on the generator to send the signal to the timing ref output, so you could select a second channel as the timing ref output. Most measurements are better made individually, if a timing reference is used when measuring you can subsequently get any desired combination by summing measurements using trace arithmetic.
 
Hi John!

I ran into the following errors when using the API. I'm still trying to see if I can narrow down the issues on my end to identify exactly what's causing the errors. But I thought I'd leave the stack trace here first as you might be able to glean something from them:


Code:
REW V5.40 Beta 113 running Eclipse Adoptium JRE 11.0.29 64-bit on OS X 15.7.3 Language en, country US, keyboard US, UTF-8 Screen 2560 x 1440 at 109 DPI Running in /Applications/REW
 

Message:
    java.lang.ArrayIndexOutOfBoundsException: Index 32767 out of bounds for length 32767
Stack Trace:
Index 32767 out of bounds for length 32767
    roomeqwizard.LA.h(y:2641)
    roomeqwizard.LA.b(y:3374)
    roomeqwizard.LA.F(y:2375)
    roomeqwizard.LA.preferenceChange(y:979)
    java.prefs/java.util.prefs.AbstractPreferences$EventDispatchThread.run(AbstractPreferences.java:1543)

Code:
REW V5.40 Beta 113 running Eclipse Adoptium JRE 11.0.29 64-bit on OS X 15.7.3 Language en, country US, keyboard US, UTF-8 Screen 2560 x 1440 at 109 DPI Running in /Applications/REW
 

Message:
    java.lang.NullPointerException
Stack Trace:
    roomeqwizard.LA.h(y:2942)
    roomeqwizard.LA.b(y:3374)
    roomeqwizard.LA._(y:3496)
    roomeqwizard.graphgroup.P$5.actionPerformed(y:3028)
    java.desktop/javax.swing.JComboBox.fireActionEvent(JComboBox.java:1264)
    java.desktop/javax.swing.JComboBox.setSelectedItem(JComboBox.java:589)
    roomeqwizard.graphgroup.P.A(y:974)
    roomeqwizard.api.RTAService$4.run(y:1168)
    java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
    java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
    java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
    java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
    java.base/java.security.AccessController.doPrivileged(Native Method)
    java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
    java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
    java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
    java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
    java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
    java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
    java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)


Code:
REW V5.40 Beta 113 running Eclipse Adoptium JRE 11.0.29 64-bit on OS X 15.7.3 Language en, country US, keyboard US, UTF-8 Screen 2560 x 1440 at 109 DPI Running in /Applications/REW
 

Message:
    java.util.concurrent.ExecutionException: java.lang.NullPointerException
Stack Trace:
java.lang.NullPointerException
    java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
    java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
    java.desktop/javax.swing.SwingWorker.get(SwingWorker.java:613)
    roomeqwizard.L.A$2.done(y:2059)
    java.desktop/javax.swing.SwingWorker$5.run(SwingWorker.java:750)
    java.desktop/javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.run(SwingWorker.java:847)
    java.desktop/sun.swing.AccumulativeRunnable.run(AccumulativeRunnable.java:112)
    java.desktop/javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.actionPerformed(SwingWorker.java:857)
    java.desktop/javax.swing.Timer.fireActionPerformed(Timer.java:317)
    java.desktop/javax.swing.Timer$DoPostEvent.run(Timer.java:249)
    java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
    java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
    java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
    java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
    java.base/java.security.AccessController.doPrivileged(Native Method)
    java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
    java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
    java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
    java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
    java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
    java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
    java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Caused by:
    java.lang.NullPointerException
    roomeqwizard.siggen.K.A(y:6463)
    roomeqwizard.siggen.K.I(y:2048)
    roomeqwizard.siggen.K.A(y:1001)
    roomeqwizard.siggen.F.ʠ(y:505)
    roomeqwizard.siggen.F$9.C(y:1436)
    roomeqwizard.L.A$2.A(y:238)
    roomeqwizard.L.A$2.doInBackground(y:3207)
    java.desktop/javax.swing.SwingWorker$1.call(SwingWorker.java:304)
    java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    java.desktop/javax.swing.SwingWorker.run(SwingWorker.java:343)
    java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    java.base/java.lang.Thread.run(Thread.java:829)
 
The first two are coming from RTA initialisation, likely caused by changes to RTA settings while it is still processing a previous change. You must wait for a response from all API calls before issuing another call, if you are not doing that. The third is from the signal generator, when it is trying to show preview data for a multitone sequence before the sequence has been generated. Not sure how that's possible, again perhaps by issuing repeated API calls without waiting for responses.
 
The first two are coming from RTA initialisation, likely caused by changes to RTA settings while it is still processing a previous change. You must wait for a response from all API calls before issuing another call, if you are not doing that. The third is from the signal generator, when it is trying to show preview data for a multitone sequence before the sequence has been generated. Not sure how that's possible, again perhaps by issuing repeated API calls without waiting for responses.

Understand; thank you!

For the RTA settings, it does seem like that is indeed the case. For reference, here is the python code that I'm running. Putting sleep timers of a few seconds before each line seems to resolve the issue. I will experiment more with the multitone generator


Code:
import requests
import json
import time


BASE_URL = "http://localhost:4735"

def rew_put_json(endpoint, payload):
    
    r = requests.put(
        f"{BASE_URL}{endpoint}",
        json=payload
    )
    r.raise_for_status()
    # print(f"API response: {r.json()}")
    return r.json()

def rew_post_json(endpoint, payload):
    
    r = requests.post(
        f"{BASE_URL}{endpoint}",
        json=payload
    )
    r.raise_for_status()
    # print(f"API response: {r.json()}")
    return r.json()



sample_rate = 192000
r = rew_post_json("/audio/samplerate", {'value':sample_rate,'unit':'Hz'})

print(f"Starting RTA...")
rew_post_json("/rta/command", {"command": "Start"})

time.sleep(3)

print(f"Stopping RTA...")
rew_post_json("/rta/command", {"command": "Stop"})


sample_rate = 48000
r = rew_post_json("/audio/samplerate", {'value':sample_rate,'unit':'Hz'})

default_rta_settings = {"fftLength": "64k"}
r = rew_post_json("/rta/configuration", default_rta_settings)
# r = rew_put_json("/rta/configuration", default_rta_settings) # Running the put command doesn't work either.
 
Hi John,
I am again trying to prove that Arcam can't implement Dirac in their receivers. Today I see that in the info of REW measurement. My laptop is on Win11 and the info shows Win10. What do I miss? I can sleep with that but just in case it could be important against Harman Luxury...

1770224343061.png
 
Understand; thank you!

For the RTA settings, it does seem like that is indeed the case. For reference, here is the python code that I'm running. Putting sleep timers of a few seconds before each line seems to resolve the issue. I will experiment more with the multitone generator
Use the API in blocking mode. Setting the sample rate will trigger a re-init of the RTA, that may still be in progress when you set the RTA length, leading to the error. I'll see about stopping that from causing an issue in the next build.
 
Hi John, I’ve encountered something that doesn’t really make sense to me. I’m using the stepped measurement feature to measure the IMD vs level for my DAC.

After running the measurement, I saved the current RTA stepped measurement graph to the main window. I only have 1 measurement loaded in the main window. When queuing the graph’s distortion using the API, I seem to be getting results that don’t line up with the graph at all.

I've attached a capture of my graph and the .mdat file. Below are the results from the API call.

According to the graphs, the TD+N (%) takes values between values between 1 and ~6e-3.
Likewise the IMD_SMPTE curve takes values of ~0.02% toward the left and bottom out around 5e-4%.

Below is the output I get when I query for the distortion values using the API. For IMD and TD+N, there are no values close to what is shown in the graph. The results would suggest a flat line for all the data. Would you happen to know what might be happening?

Stepped measurement settings:
- IMD vs Level: SMPTE
- Start level: -60 dBFS
- End level: -2 dBFS
- Stepsize: 2 dBFS


Code:
{'measurement': 'Stepped IMD SMPTE',
 'type': 'IMD SMPTE (60 Hz & 7 kHz 4:1) vs level',
 'columnHeaders': ['Gen (dBFS)',
  'Fundamental (dB)',
  'IMD (%)',
  'TD+N (%)',
  'Noise (%)'],
 'data': [[57.429, 103.018, 0.231, 0.488, 0.011],
  [59.429, 103.018, 0.231, 0.488, 0.011],
  [61.429, 103.018, 0.231, 0.488, 0.011],
  [63.429, 103.018, 0.231, 0.488, 0.011],
  [65.429, 103.018, 0.231, 0.488, 0.011],
  [67.429, 103.018, 0.231, 0.488, 0.011],
  [69.43, 103.018, 0.231, 0.488, 0.011],
  [71.429, 103.018, 0.231, 0.488, 0.011],
  [73.43, 103.018, 0.231, 0.488, 0.011],
  [75.43, 103.018, 0.231, 0.488, 0.011],
  [77.43, 103.018, 0.231, 0.488, 0.011],
  [79.43, 103.018, 0.231, 0.488, 0.011],
  [81.43, 103.018, 0.231, 0.488, 0.011],
  [83.43, 103.018, 0.231, 0.488, 0.011],
  [85.43, 103.018, 0.231, 0.488, 0.011],
  [87.43, 103.018, 0.231, 0.488, 0.011],
  [89.43, 103.018, 0.231, 0.488, 0.011],
  [91.43, 103.018, 0.231, 0.488, 0.011],
  [93.43, 103.018, 0.231, 0.488, 0.011],
  [95.43, 103.018, 0.231, 0.488, 0.011],
  [97.43, 103.018, 0.231, 0.488, 0.011],
  [99.43, 103.018, 0.231, 0.488, 0.011],
  [101.43, 103.018, 0.231, 0.488, 0.011],
  [103.43, 103.018, 0.231, 0.488, 0.011],
  [105.43, 103.018, 0.231, 0.488, 0.011],
  [107.43, 103.018, 0.231, 0.488, 0.011],
  [109.43, 103.018, 0.231, 0.488, 0.011],
  [111.43, 103.018, 0.231, 0.488, 0.011],
  [113.43, 103.018, 0.231, 0.488, 0.011],
  [115.427, 103.018, 0.231, 0.488, 0.011]]}
 

Attachments

Use the API in blocking mode. Setting the sample rate will trigger a re-init of the RTA, that may still be in progress when you set the RTA length, leading to the error. I'll see about stopping that from causing an issue in the next build.
Thank you! I will take a look at this.

Meanwhile I added a small delay in my function that makes the api calls and I’ve not ran into any errors since!
 
I’ve encountered something that doesn’t really make sense to me. I’m using the stepped measurement feature to measure the IMD vs level for my DAC.
Stepped measurements are saved automatically when the measurement ends. If you are doing a manual save after that you are probably just capturing the last point of the step sequence.
 
Measurements made with the 5.40 beta build will correctly identify Windows 11. Windows 11 actually identifies itself as Windows 10 when asked for the OS version, but with a different build number.
my version is 5.31.3 . I should have mentionned it. No big deal.
 
Stepped measurements are saved automatically when the measurement ends. If you are doing a manual save after that you are probably just capturing the last point of the step sequence.

hmm even without the manual save, the API still returns only the final value it seems.

For measurements obtained from sweeps, calling the "/measurements/{id}/distortion?unit=percent" endpoint works well to return the values in the units requested to plot the distortion graph in the main window.

Somehow this doesn't work if the graph is created from stepped sine measurements via the RTA.
 
John, please explain what kind of smoothing I see as a sum when two measurements are loaded into the alignment tool without smoothing? Why, when creating the sum of two unsmoothed measurements, the result in the HF part is not similar to what I see in the alignment tool? There are two cases in the pictures. The result of the sum is not smoothed + the sum in the alignment tool. The result of the sum is smoothed to 1/48 + the sum in the alignment tool.
 

Attachments

  • sum with 1_48 smoothing.PNG
    sum with 1_48 smoothing.PNG
    241.3 KB · Views: 8
  • sum without smoothing.PNG
    sum without smoothing.PNG
    270.5 KB · Views: 8
The alignment tool works with 96 ppo log-spaced copies of the measurements so that real-time adjustment is possible, since each log-spaced measurement has about 1k points rather than the typically 128k of linear-spaced measurements. Log spaced measurements are smoothed to half the PPO to prevent aliasing effects.
 
Got it. Thank you. If you look at the area around 12 kHz in the alignment tool, it seems that there are small peaks, the rest of the frequency response is beautiful, with no holes. But if you look at a section of about 12 kHz after smoothing 1/48, there is a big hole. And this pit is visible on the unsmoothed graph. So why isn"t it visible when smoothing 96 ppo?
 
I don't see what you are referring to or why it could possibly matter, but 96 PPO data is smoothed to 1/48 as part of the conversion to log spacing.
 
why it could possibly matter
I increased the X axis. Consider a frequency of 11.521 kHz. In the top graph, the black solid line shows what the frequency response will look like if you add up measurement 1 and measurement 2. At the point 11.521 kHz you should get 73.2 dB at 96 ppo. The blue graph (unsmoothed) against a black background turned out when I clicked the Aligned sum button. I expected 73.2 dB, but got 82 dB. I expected a hole, but after adding it up there is none.
Further. In the section after 11.5 kHz to 12.5 kHz, the black graph does not show a hole. But after addition it is there (blue graph).
From 13.5 kHz to 15.5 kHz, the amplitude of the black graph changes so that it cannot be called flat. The actual sum (blue graph) is almost flat.
After 17 kHz, the black graph shows a shifted hole relative to blue. 17.7 kHz has 66 dB for black and 78 dB for blue.
It seems to me that such discrepancies between the expected frequency response and that obtained after actual addition should be important.
 

Attachments

  • alignment tool question.PNG
    alignment tool question.PNG
    681.4 KB · Views: 2
Back
Top