# HubeRSoundX and the case for a global audio equaliser built on DynamicsProcessing

> HXAudio is an Android app that applies a global equaliser and limiter using the platform DynamicsProcessing API, with a custom HxCore algorithm that computes per-channel curves and pre-renders frequency responses before the main equaliser runs. What the repository does not contain is the source code itself, only the write-up.

**HuberHaYu/HubeRSoundX** — （HXAudio）无需任何高级权限的强力音频处理App

- Repository: https://github.com/HuberHaYu/HubeRSoundX
- Website: https://huberhayu.github.io/HubeRSoundX/
- Stars: 698 · Forks: 25
- Language: Unknown
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/huberhayu-hubersoundx

## The scope claim and the three places it does not apply

HXAudio, called HX for short, is described as a powerful audio processing app that needs no advanced permissions, and it is compatible with Android 10 and later. The claim is that it works globally, but the project is careful to list the cases where it may not.

There are three. Calls are first, and that is a hardware and platform limitation rather than a bug: the audio path for a phone call is not a normal media stream, so a global effect has nothing to attach to. The second is games with offload and a low latency mode, some rhythm games and some MOBA titles, where the audio is handled by a fast path that bypasses the normal mixer. The third is music players and games that have enabled AAudio or OpenSLES low latency.

Listing those explicitly is more useful than a blanket global claim, because a user who hits one of them now knows why rather than assuming the app is broken. It also tells you the app is built on the standard Android audio session path, which is what makes the no-permission claim true, and which is also what makes the three exclusions inevitable.

The release history is short and recent. The tags are v7.0 from 2025-12-13, v7.0.1 from 2026-01-09 and v8 from 2026-07-06, and the last push to the repository was on 2026-07-06, the same day as the newest release.

## HxCore computes the curve, DynamicsProcessing applies it

The distinctive part of the project is an algorithm it calls HxCore, described as built on the DynamicsProcessing API, doing equalisation and frequency response curve computation, with multi-channel logic to compute an independent equaliser per channel to simulate different sound phases.

The structure of the code shows how that works. The equaliser bands are DynamicsProcessing.EqBand arrays, allocated for the pre-stage band count, and each band is constructed with a frequency, a gain and a flag:

```java
private void initializeEqBands(float[] freq, float[] freq_t, float[] gain_on, float[] gain_on_t) {
    eqBands = new DynamicsProcessing.EqBand[HxControlCore.maxBandCount_Pre];
    eqBands_T = new DynamicsProcessing.EqBand[HxControlCore.maxBandCount_Pre];
    if (freq == null) {
        freq = HxControlCore.frequencies_jbl_flip;
    }
    if (freq_t == null) {
        freq_t = HxControlCore.frequencies_jbl_flip;
    }
    if (gain_on_t == null) {
        gain_on_t = Default;
    }
    for (int i = 0; i < HxControlCore.maxBandCount_Pre; i++) {
        eqBands[i] = new DynamicsProcessing.EqBand(true, freq[i], gain_on[i]);
        eqBands_T[i] = new DynamicsProcessing.EqBand(true, freq_t[i], gain_on_t[i]);
    }
}
```

The overload that takes only the gains passes nulls for the frequencies, so the frequency table is shared while the gain table is per call. Two band arrays are kept in step, one for the main path and one for the pre-render path, and the frequencies default to a table named after a speaker curve.

The equalisation is described as happening on top of an adjustable ten band equaliser, with a second audio rendering pass so the hardware can be pushed further than the stock path allows. The comparison drawn in the write-up is with Wavelet and Poweramp, and the claim is that HX drives the low frequency dynamic range of speakers, headphones and cabinets much harder than those two do.

## Pre-rendering happens before the main equaliser sees the audio

The second distinctive feature is described as multi-band pre-stage impulse, performing a rendering of the audio before it reaches the later stage equaliser, so that the optimal frequency response of a device can be simulated, including surround and monitoring response curves.

The curve data is a set of flat float arrays, one per speaker profile:

```java
public static float[] HxCore_Surround_L = {0, 6f, 3, 0, 5, 2, 5, 3, 0, 0, 0};
public static float[] HxCore_Surround_R = {0, 5, 0, 0, 2.5f, 0, 3, 3, 0, 0, 0};
public static float[] JBL_Flip = {0, 0, 10, 7, 1.2f, 0, -2, -2.5f, 0, 0, 0};
public static float[] JBL_PartyBox = {0, 9, 3.6f, 0, 0, 0, 0, 0, 0, 0, 0};
public static float[] Origin_Voice = {4f, 1.5f, -0.44f, 0.7f, 2f, -4.5f, 0.2f, 1.7f, 3f, 0.8f, 0};
public static float[] N12T_Origin = {9, -1, -6.6f, -4, 8.5f, -7.7f, -2.35f, -6, 1, 1, 1};
public static float[] JBL_PS3300 = {1.5f, 5f, 3.7f, 1.9f, -3.6f, 1.5f, 3f, 1.9f, 1.75f, 1f, 0.6f};
public static float[] Default = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
```

Each array holds eleven values, which is ten band gains plus a trailing entry. The profiles are named after actual hardware, a JBL flip speaker, a JBL party box, an Origin voice monitor, an N12T origin, a JBL PS3300, and separate left and right arrays for a surround simulation, with a flat Default as the neutral case.

The separate left and right surround arrays are the detail that gives the per-channel claim its meaning. A surround curve that is symmetric would be a single array applied twice, and the fact that there are two different ones means the phase relationship between channels is being modelled rather than assumed.

## The limiter is where the low frequency protection comes from

Alongside the equaliser, the app runs a multi-band compressor, and the write-up says the same HxCore algorithm is used to pass its parameters in.

The limiter is configured with named constants rather than magic numbers:

```java
private static final float LIMITER_DEFAULT_ATTACK_TIME = 1;
private static final float LIMITER_DEFAULT_RELEASE_TIME = 60;
private static final float LIMITER_DEFAULT_RATIO = 10;
private static final float LIMITER_DEFAULT_THRESHOLD = -2; 
private static float LIMITER_DEFAULT_POST_GAIN = 0;
public static DynamicsProcessing.Limiter HxCore_LIMITER;
```

And the multi-band compressor bands are built with the same pre-band array and a set of additional per-band values:

```java
private void initializeMbcBands(float[] freq, float[] gain_on) {
    eqBands_Mbc = new DynamicsProcessing.MbcBand[HxControlCore.maxBandCount_Pre];
    if (freq == null) {
        freq = HxControlCore.frequencies_jbl_flip;
    }
    for (int i = 0; i < HxControlCore.maxBandCount_Pre; i++) {
        eqBands_Mbc[i] = new DynamicsProcessing.MbcBand(true, freq[i],
                LIMITER_DEFAULT_ATTACK_TIME,
                LIMITER_DEFAULT_RELEASE_TIME,
                LIMITER_DEFAULT_RATIO,
                LIMITER_DEFAULT_THRESHOLD,
                3.5f,
                2f,
                1.1f,
                2,
                gain_on[i]);
    }
}
```

The stated purpose is to work together with the DynamicsProcessing limiter to prevent excessive low frequency current noise as far as possible, and to prevent audio popping.

That last point is the one that matters practically. Driving a small speaker with a large low frequency boost is a good way to make it distort badly, and a limiter with a threshold of -2 and a ratio of 10 is how you keep the boosted signal from clipping the output stage. The compressor bands are per band rather than global, which is what lets the low end be limited harder than the rest.

## Where to get the app, and what the version numbers say

There is no install command in the project description and no build instructions in the repository, so the app itself is obtained from outside the code. The homepage is huberhayu.github.io/HubeRSoundX/, and the version tags give you the history of the binaries.

The numbering is a plain major scheme with a v8. The tags are v7.0 from 2025-12-13, v7.0.1 from 2026-01-09 and v8 from 2026-07-06, so the project moved from a 7 line to an 8 line within about seven months, with a point release in between. The last push to the repository was on 2026-07-06, the same day as the v8 tag, which tells you the documentation and the release were updated together.

The version jump is worth reading as a signal rather than a detail. A major bump in an app that sits on top of a platform audio API usually means a platform target changed, a new Android release was adopted, or the processing pipeline was restructured. The project description says the app is compatible with Android 10 and later, and given that the DynamicsProcessing API has been reshaped more than once, a new major version is what you would expect when the underlying API moves.

For a user, the practical checklist is short. Confirm the Android version is 10 or newer, install the current major release rather than the last point release of the previous major, and expect the three documented exclusions to apply. For anyone evaluating the algorithm, the repository is a description of what the app does rather than an implementation you can audit, and the curve tables are the most concrete part of it.

## The repository holds a write-up, not the code

This is the fact that most affects how you should treat the project.

The repository has exactly one top-level entry, and it is the project description file. There is no source directory, no build file, no licence file and no project metadata beyond that document. Everything the project documents is described in prose and in the Java snippets quoted from its implementation.

That has a few consequences. You cannot read the implementation, only the parts the author chose to show, which are the band construction routines and the curve tables. You cannot build it from this repository, and you cannot check whether the app does what the description claims, because there is nothing here to check against. And you cannot tell how the app is distributed, because the write-up points to a homepage rather than to a build or a package.

The homepage is huberhayu.github.io/HubeRSoundX/, and the project is not archived, so the last push on 2026-07-06 was recent enough to be current. The licence is not recorded for the repository, which is unusual and worth noting for anyone thinking about redistributing or reusing the curve tables.

What the write-up does give you is the algorithm's shape, and the curve tables are genuinely informative. A JBL flip profile peaking at +10 and +7 in the low bands, or a PS3300 profile with a positive low end and a dip, tells you what the author believes those speakers do, and the fact that the curves are named after real models rather than generic shapes suggests they were measured rather than invented.

## Conclusion

HXAudio suits an Android listener on a device with poor speakers who wants a real equaliser and limiter applied to system audio without root, since that is what the DynamicsProcessing API provides and the app builds on it directly. It does not suit a developer looking to read or extend the code, because the repository contains only a project description file, and it does not suit someone whose content is a phone call or a low latency game, since the project states those cases may not work. Before you install it, check that your Android version is 10 or newer, and note that the latest release is v8 from 2026-07-06 with the last push on the same day, and that no licence is recorded for the project.

## FAQ

### What is HubeRSoundX?

It is an Android audio processing app, also called HXAudio, that needs no advanced permissions and is compatible with Android 10 and later. It applies a global equaliser and limiter built on the Android DynamicsProcessing API, with a custom HxCore curve algorithm for the equalisation and per-channel calculation.

### In which situations does HubeRSoundX not work?

The project lists three. Calls, because the call audio path is not a normal media stream. Games with offload and a low latency mode, such as some rhythm games and MOBA titles. And music players or games that have enabled AAudio or OpenSLES low latency, since those use a fast path that bypasses the normal mixer.

### What does the HxCore algorithm do?

It is built on the DynamicsProcessing API and does the equalisation and frequency response curve computation, using multi-channel logic to calculate an independent equaliser for each channel so different sound phases can be simulated. It also pre-renders the audio before the later stage equaliser so a device's optimal response can be simulated.

### Is the source code of HubeRSoundX available?

Not in the repository. The only top-level entry is the project description file, so the implementation cannot be read or built from there, only the Java snippets the author chose to include. The project points to a homepage instead, and no licence is recorded for the repository.

### What are the latest HubeRSoundX releases?

The listed tags are v8 from 2026-07-06, v7.0.1 from 2026-01-09 and v7.0 from 2025-12-13, and the last push to the repository was on 2026-07-06, the same day as the newest release.

## Sources

- [HuberHaYu/HubeRSoundX on GitHub](https://github.com/HuberHaYu/HubeRSoundX)
- [Issues](https://github.com/HuberHaYu/HubeRSoundX/issues)
- [Project website](https://huberhayu.github.io/HubeRSoundX/)
- [README](https://github.com/HuberHaYu/HubeRSoundX/blob/main/README.md)
- [Releases](https://github.com/HuberHaYu/HubeRSoundX/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/huberhayu-hubersoundx