REW Beta Release REW API beta releases

Not sure when this was implemented, but it appears that the calculations are limited to 20hz and 19K? It's not a big deal, I just wanted to know if there's a setting where cutting the calculations off at these limits?

REW LIMITS.png
 
This thread is for beta releases of the REW API. Here are the download links (updated 14th March 2024):

Windows 64-bit
Windows 32-bit
MacOS
Linux AMD 64
Linux no JRE

The API is REST(ish) with webhooks. Here is the online help. The API documentation is served by swagger-ui and can be accessed by browsing to localhost:4735 after starting the API server, either from the Preferences API tab or by launching REW with the -api argument. The OpenAPI specification for the API can be accessed at localhost:4735/doc.json or localhost:4735/doc.yaml for JSON or YAML formats. The swagger UI has links to the relevant help section.

The API is a work in progress, the help and the OpenAPI specification list the endpoints that have been implemented so far but there are others yet to do.
Thanks John for your constant efforts to improve the REW Program. Thanks for all your efforts and support as always.
 
Dear John,

Cross correlation align slows down considerably while working with generated responses rather than loaded measurements independent of the number of responses aligned. Is this fixable or a design necessity?

Thanks.
 
"Vector average" also behaves similar.
 
Sorry, stupid question. It's because sample lengths increase during operations. Please ignore!
 
This thread is for beta releases of the REW API. Here are the download links (updated 14th March 2024):

Windows 64-bit
Windows 32-bit
MacOS
Linux AMD 64
Linux no JRE

The API is REST(ish) with webhooks. Here is the online help. The API documentation is served by swagger-ui and can be accessed by browsing to localhost:4735 after starting the API server, either from the Preferences API tab or by launching REW with the -api argument. The OpenAPI specification for the API can be accessed at localhost:4735/doc.json or localhost:4735/doc.yaml for JSON or YAML formats. The swagger UI has links to the relevant help section.

The API is a work in progress, the help and the OpenAPI specification list the endpoints that have been implemented so far but there are others yet to do.
The Win 64 download is not working. I get the following error message: DNS_PROBE_FINISHED_NXDOMAIN.
 
I can’t get the MAC OS to start downloading manually off the links. I wanted to get the beta Installed to try Audyessy One. When I open REW it is not checking for a beta update either. I do have that box checked so that it should. Am I doing something wrong.
 
There was an issue with the site nameservers that affected the DNS info, it should resolve over the next few hours.
 
Thanks so much for the quick reply. I thought I was doing something wrong. Have a great day and thanks again for your work on REW
 
There was an issue with the site nameservers that affected the DNS info, it should resolve over the next few hours.
Problem seems to have been solved for me.
 
I cannot use Java EXCLusive drivers for the Motu UltraLite MK5 mic inputs for some reason. It works fine with ASIO. Windows privacy settings are ok. What do you think is wrong here?

1711519688517.png
 
Last edited:
If ASIO4All is running at the same time and the card is selected, it could be blocking the card for itself.
 
If ASIO4All is running at the same time and the card is selected, it could be blocking the card for itself.
I turned it off and got the same error when I re-opened REW though.
 
I would try setting a different device as capture default, to make sure the windows subsystem does not block the card (despite those "exclusive" checkboxes which may or may not work). Also I would check that really no other software is accessing the device (e.g. some other ASIO bridge like FlexASIO etc.)


If none of that is confirmed (which still does not give 100% certainty because IIUC there is no simple/non-programmatic way to find out what process is using an audio device in windows), the debug logs from the EXCL dll would be needed to check what is going on - described e.g. in https://www.avnirvana.com/threads/v5-20-10-early-access.10787/page-5#post-82326
 
It's also selectively blocking my USB mic with EXCL. Normal Java drivers work! Thanks for all the suggestions.
 
no other software is accessing the device
The Motu comes with a software interface (CueMix 5) and terminating that doesn't help either.
 
I've managed not to be able to combine subwoofer and front left speaker preamp outputs and take measurements with a high end audio interface :(
 
It's also selectively blocking my USB mic with EXCL.
I am afraid I do not understand
Normal Java drivers work!
"Normal java drivers" communicate through the windows audio layer which can do many things, more than what you see in the GUI. Whereas the wasapi exclusive access talks directly to the driver, no resampling, no stream merging, no sample conversion.

Thanks for all the suggestions.
Well, the debug log is the first step to go. No exact idea what happens on your system, but 2 cents it's another process preventing REW from accessing your audio device directly or your device is hard-switched to some other samplerate somehow (as happens e.g. with devices clocked by incoming SPDIF stream), or anything else.

In linux you could directly see all the details of what is going on, what parameters a device supports, what parameters the device is currently running with, what processes are currently accessing the device. Windows is a black box which unfortunately requires trial/error.
 
Could you provide a link to read how this happens?
If you are using an S/PDIF input it gets its clock from the source data, so the sample rate of the input is determined by the rate at which the source transmits.
 
For capture rate it's quite obvious. Actually I meant the somewhat more complex effect on the playback rate.

If a device supports switching to incoming SPDIF clock and supports only common capture and playback rate, then the playback part runs at the same samplerate as the capture which is controlled by the incoming samplerate. The driver should limit the available playback rates when the card runs at the incoming SPDIF rate.

An example of such device is ESI Juli@. Its SPDIF receiver AK4114 can measure the incoming SPDIF rate and its PCI controller ICE1724 (Envy24HT) can switch its master clock between one of the two crystals and the mclk generated by the SPDIF receiver.

I do not know what the windows driver for that device does, but the linux driver limits the capture HW params to the currently detected samplerate https://github.com/torvalds/linux/b...0961e023ee/sound/pci/ice1712/juli.c#L163-L181 . Since the driver makes sure capture and playback can run on the same samplerate only https://github.com/torvalds/linux/b...150961e023ee/sound/pci/ice1712/ice1712.h#L334 (that's how the ICE1712/24 controller is designed), this limitation for capture also limits the available playback samplerates.
 
Feature request: Please add support for M-noise ! https://m-noise.org/
It's a really great way to test modern systems that have a DSP compressor, putting devices that don't have a DSP on a level playing field with those who do. It enables to fully asses the linear range of a speaker system when listening to a high crest-factor source (ie. most music).
 
Last edited:
Back
Top