gpuRIR moves the Image Source Method onto a CUDA GPU

Room acoustics research that needs thousands of impulse responses

A room impulse response is the acoustic fingerprint of a space: how a sound at one point arrives at another point after bouncing around. It is the input to every convolution reverb, to source localisation research, and to microphone array work.

The Image Source Method is how you compute one. You mirror the source and receiver across every wall, floor and ceiling, treat each mirror image as a straight line path, and sum the delayed and attenuated contributions until the tail is inaudible. The cost grows with the number of images, which grows with the reverberation time you want to model, which is why RIR simulation has always been a slow job.

gpuRIR is a Python library that runs that computation on CUDA GPUs and computes the RIRs between several source and receiver positions in parallel. The project states that it is approximately 100 times faster than CPU implementations, and points to the paper in its references for the comparison.

The user is specific: someone doing acoustic research, room simulation for speech or audio machine learning, or microphone array design, who needs RIRs for many positions rather than one. For a single short RIR, a CPU implementation is fine and you do not need this library at all.

The build needs CUDA, CMake and a C++ compiler

gpuRIR is not a pure Python package. It compiles CUDA and C++ sources at install time, which sets the requirements before you write a single line of your own code.

The documented prerequisites are the NVIDIA CUDA Toolkit, which has been tested with releases 8.0 and 10.0 but is expected to work with any version that includes cuRAND, a C++11 compiler such as GCC or MSVC++, and CMake version 3.23 or later. The documentation notes that CMake can be obtained with `pip install cmake`. Python 3 is what it has been tested in, with Python 2 expected to work as well.

The build system is CMake driven through a setuptools extension. The project metadata declares the build requirements as setuptools, wheel and cmake at 3.23 or newer, with setuptools.build_meta as the backend.

[build-system]
requires = ["setuptools", "wheel", "cmake>=3.23"]
build-backend = "setuptools.build_meta"

The setup script checks the CMake version explicitly and raises a clear error when it is too old on Windows, comparing the parsed version against 3.23.0.

One constraint is easy to miss. If you intend to use gpuRIR with PyTorch, the compiler used to build gpuRIR must be ABI compatible with the compiler PyTorch was built with, which the documentation says means using GCC version 4.9 and above.

Installing from the repository, and what the packaging declares

The documented installation routes are pip from the GitHub repository, using the zipball URL for the master branch, or cloning or downloading the repository and running pip install on the local gpuRIR directory.

Those two commands appear inline in the project documentation rather than in a copyable block, so the exact strings to paste are the pip install call for the repository zipball and the pip install call on the local gpuRIR folder.

The package metadata in pyproject.toml gives the identity of what gets installed.

[project]
name = "gpuRIR"
version = "1.2.0"
description = "Room Impulse Response (RIR) simulation through Image Source Method (ISM) with GPU acceleration"

Two details in that metadata are worth flagging. The classifiers list both Python 2 and Python 3 and a C++ entry, and the licence classifier names the GNU Affero General Public License v3 or later.

[project.optional-dependencies]
dev = ["pytest"]

The dev extra is just pytest, so the test suite is the only thing you add for development work. The repository root also holds a CMakeLists.txt, a src directory for the compiled sources, a third_party directory, a gpuRIR package directory, and an examples folder with scripts named example.py, polar_plots.py, simulate_trajectory.py, time_vs_T60.py and time_vs_nbRIRs.py, which tells you the examples cover polar patterns, trajectories and timing behaviour.

simulateRIR takes room geometry, wall coefficients and positions

The main entry point is simulateRIR, and its parameter list is where the physics shows through.

room_sz is the room size in meters with three elements. beta is the reflection coefficient of each wall as six values ordered by axis and side, beta_x0 and beta_x1 for the walls orthogonal to the x axis, then the y pair and the z pair. pos_src and pos_rcv are arrays with two dimensions and three columns, holding source and receiver positions in meters. nb_img gives the number of images simulated in each dimension, Tmax the length of the RIR in seconds, and fs the sampling frequency in Hertz. The speed of sound c defaults to 343.0.

Two optional parameters matter for realism. Tdiff is the time at which the Image Source Method is replaced by a diffuse reverberation model, which by default equals Tmax, meaning a full ISM simulation. spkr_pattern and mic_pattern set the polar pattern of the sources and receivers, with the choices omni, homni, card, hypcard, subcard and bidir, and omni as the default.

The return value is a three dimensional ndarray whose first axis is the source, the second the receiver and the third is time.

That shape is the whole reason to use a GPU here. You are asking for every source against every receiver in one call, and the kernel does the work in parallel rather than looping in Python.

GPU memory is the failure mode to plan for

The documentation contains a warning worth reading twice, because it is the one place the library tells you it can fail outright: asking for too much and too long RIRs, especially for full ISM simulations, may exceed the GPU memory and crash the kernel.

There is no error handling or chunking described for that case. The kernel simply does not fit, and the failure surfaces as a crash rather than an exception you can catch and retry with smaller parameters. So the parameter choice is not only an accuracy decision, it is a memory budget decision.

The two switches that give you room are in the API. activateMixedPrecision turns on mixed precision mode, which the documentation restricts to Pascal GPU architecture or superior. activateLUT turns on the lookup table used for the sinc computations. Both default to active, and both can be switched off, which is the lever you would pull if you are memory constrained on an older card.

Two helper functions exist to size the job before you run it. t2n estimates the number of images needed for a correct RIR simulation given a time parameter, and beta_SabineEstimation derives the six wall reflection coefficients that produce a desired reverberation time T60, with optional absorption weights per wall defaulting to equal ratios. A third helper, att2t_SabineEstimator, gives the time at which the RIR reaches a requested attenuation in dB for a given T60. Estimating the image count first is the practical way to avoid the crash.

Moving sources and microphones with simulateTrajectory

A second function covers the case where nothing stays still. simulateTrajectory filters an audio signal by the RIRs of a motion trajectory recorded with a microphone array.

You give it the source signal, the RIRs produced by simulateRIR, and optionally the timestamps of each RIR. By default the RIRs are assumed equispaced through the trajectory, and the sampling frequency fs is only needed for custom timestamps. The result is a two dimensional matrix with the signals captured by each microphone in each column.

So the intended workflow is a two stage one. First compute the RIR set for the trajectory positions, then convolve the moving source with those RIRs to synthesise what each microphone would have recorded. The examples folder includes simulate_trajectory.py, which is the script to look at for the exact call sequence.

The alternative to all of this is a CPU implementation of the same physics, which the project measures as roughly a hundred times slower. The difference in approach is not algorithmic, it is where the arithmetic happens: the same image source method, with the source and receiver sweep moved onto the GPU so that a batch that would take hours on a CPU runs as one parallel job. If your workload is a single RIR for a single source and receiver, that advantage is irrelevant.

AGPL terms, no release tags, and a build you own

The licence is AGPL-3.0, and the documentation states that the library comes with no warranty and asks you to acknowledge it in your research work if you find it useful.

The AGPL is the part to think about carefully if you plan to build this into a service or a product, because it is designed to reach network use, not just distribution. Whether it applies to your situation depends on how you deploy and whether you modify the library, and that is a question for your own counsel rather than for a review article. What matters practically is that the alternative licences commonly chosen for research code, MIT or BSD, are not available here.

On maintenance, the repository is not archived and the last push was on 2026-08-25, but the repository has no GitHub releases, so there is no tag history to check and no release notes to read. The only version marker is the 1.2.0 in pyproject.toml. That means your upgrade path is to reinstall from master and diff the source yourself, which is a rougher process than consuming tagged releases.

Combined with the fact that you are compiling CUDA and C++ at install time, that is the shape of the dependency: a source-level, GPU-bound, copyleft library that you build and track yourself.

Editorial conclusion

gpuRIR fits an acoustics researcher or engineer who needs many room impulse responses for the same room geometry, since the Image Source Method is the accuracy you want and the GPU is what makes the source and receiver sweep affordable. It does not fit a team without an NVIDIA GPU and CUDA toolchain, a pipeline that needs a permissive licence, or a case where a handful of short RIRs would do, since the build and licence overhead exceeds the benefit there. Before adopting it, confirm your compiler is ABI compatible with your PyTorch build if you plan to use the RIRs inside a PyTorch model, decide whether the mixed precision and lookup table options help on your GPU architecture, and check the version you install against 1.2.0 in pyproject.toml, since the repository publishes no GitHub releases to track.

Frequently asked questions

Official sources

1. DavidDiazGuerra/gpuRIR on GitHub
2. Issues
3. License: AGPL-3.0
4. README