Audio visualisation error

[pallaswept]

Describe the bug

Honestly I'm not sure how to describe this. Is this aliasing? Interference? I will provide video.

A constant amplitude sound, depending on its frequency, does not have constant height bars, and, something very strange happens to things at 100Hz, 500Hz, and 5000hz
Sweeping down through the frequencies:
10k - 5k seems about right. Constant volume all the way. Until a strange thing happens at 5k.
5k - 500 Starts with way-too-high amplitude and becomes way too quiet, until the next weird jump, at 500Hz
500Hz starts out about correct volume and fades like the previous band until another weird jump at 100Hz
100Hz and things fade out after that

I tried different EQ settings and sample rates and bit depths and input methods and all kind of things, this seems pretty constant. I think it's kinda hidden by autosens.

The effect of this is extremely pronounced with a small bar count.

To Reproduce

Steps to reproduce the behavior:

This seems like it is always happening, but it is easiest to see with this config (max bars, no autosens, no NR):

[general]
bars=0
bar_spacing=0
lower_cutoff_freq=0
sensitivity=100
autosens=0
[smoothing]
noise_reduction=0

Generate a test tone and sweep it.

Expected behavior
A constant tone of constant amplitude should appear as a bar with a constant height
If this tone's frequency is swept that bar should sweep left and right but its height should remain constant.

Screenshots
I tried several tone generators (including just synths) but they all acted the same, so here's a shot with the first tone generator webpage my search engine gave me

Screencast_20250808_121639.webm

Desktop (please complete the following information):

• OS: openSUSE Tumbleweed

Terminal emulator
Any? (tested in foot and konsole)

[karlstav]

Hi,

This has to do with there being different buffers for bass mids and treble (the large buffers needed to capture the lowest frequencies would introduce too much latency for the rest of the visualisation). But there is obviously something wrong with how the output from the different buffers are "normalised", I will have a look.

[karlstav]

I made a new branch and fiddled around with some settings trying to make it better:

https://github.com/karlstav/cava/tree/frequency

However, the specific behavior around 100 and 500 Hz that you are observing is actually intended. When having a lot of bars most bars get only 1 sample in the output buffer of the FFT. These bars represents a spectrum each. But since cava has three different size buffers (bass, mid, treble) the bandwidth for each of the bands is different. It also becomes a hard cut from one bandwidth to the next. So when playing a single tone it will behave different in a bar with one bandwidth then to the next, it will occupy a relatively smaller part of the spectrum, Noise however would occupy the same part of the spectrum, regardless of bandwidth.

I will try to create a solution where I blend outputs from the different bands where they meet.

[pallaswept]

Nice Karl, thank you! I'll have a play with that branch today. I haven't done any DSP in some decades now so I am afraid I might not be of much help with this issue :(

For me, I'm not too much worried about the transition between the bins, but it's the fall-off in sensitivity/bar height as the frequencies decrease, within each bin, that's troubling me most. It doesn't seem to be there in the highest bin though?

[karlstav]

It's fun to dig around in the core stuff, but a lot of the code here is just based on trial and error to achie something that looks good, it's not meant to be a "correct" representation.

it's the fall-off in sensitivity/bar height as the frequencies decrease, within each bin, that's troubling me most.

this is because there is a hard coded eq in cava, if it wasn't you would have only ever seen the bass when listening to music.

the bandwidth of the bars are narrower towards the lower spectrum (or you would not have been able to distinguish the bass with fewer bars). But with many bars it almost becomes linear as we have a limited number of output bins from the FFT. The fall off around 5kHz is actually where we suddenly get more output bins per bar, so each bar has a wider bandwidth.

To summarize, since we have a limited "resolution" of frequencies from the audio, cava behaves strange with many bars (more than 50 per channel). If we would increase the resolution we would have to sacrifice responsiveness (larger buffers).

I found some small improvements and fixes here and there. Also I'm going to explore the blending of the output from the different bands, as there might be a noticeable break in the visualization between the bands as it is now.

[karlstav]

the blending thing was a horrible idea as the cut off frequencies of the different buffers to not match. However I found and fixed a bug in the hard coded eq that made the issue a lot less noticeable.

[pallaswept]

Thanks Karl! Appreciate you explaining the design to me so I can understand better :)

I gave the new code a try, and the transition from one bin to the next is much smoother now.

I'm still seeing that, with autosens turned off, sensitivity is really low overall. For an example I had a video playing in the background so I linked cava to that, I have autosens off and sensitivity at 100, there's just a narrator speaking over the video, video has peak volume at -1.4dB (so, the narrator is loud), all my volumes are at 100% (I muted my receiver to test it at high volume) and the sound barely registers at all:

(The top cava is the frequency branch, the bottom cava is the master branch)

I even had to take a second screenshot here, because the first one only had one bar with a tiny height and it looked like an unfair example :D I'm not too worried really, if the visualisation is strictly 'correct', but I was having trouble like this where I'd try to use cava to visualise some sound, but it just kinda wasn't hearing the sound. autosens takes care of it when the sound is constant, like playing music, but it wasn't catching random sounds among background ambience, like monitoring a room mic I could cough and cava might not move (or it might, it just depended on the noise). Sometimes even with music, I would notice like "huh, it doesn't hear the snare drums in this track".

I see what you mean about the bandwidth vs the bar count. When I first tested this for my post here, I put it on a 1440p screen to get maximum width/bars, and after your reply I tried the same thing on a 1080p screen, that '5khz ' thing happened around 3800. Interesting! The fall-off in sensitivity within the bins seems to scale fairly predictably though, I wonder if the EQ could be adjusted based on the relationship between bandwidth and bar count? I guess it might not be technically correct, but it could help with the limited bandwidth without adding latency.

Anyway, I don't intend to cause any kind of scope-creep from 'attractive visualisation' to 'analysis tool for nerds', and I agree that it's important, especially for music and speech, that the bars are quick to react. It would be cool if we could improve the sensitivity somehow, but I understand there will be a point that it is "good enough" :)

[karlstav]

I'm still seeing that, with autosens turned off, sensitivity is really low overall.

This is not the case for me, so this is strange. no autosens and sensitivity at 100 will give bars at around mid height when at peak volume. But maybe my setup is different. Could you give me the output of pw-top and maybe also wpctl inspect. Does it behave the same with all other settings in cava set to default?

I wonder if the EQ could be adjusted based on the relationship between bandwidth and bar count? I guess it might not be technically correct, but it could help with the limited bandwidth without adding latency.

I am not sure what you mean.

[pallaswept]

Weird! I hope this isn't pilot error, I really checked myself a lot. This was the config I used:

[general]
bars=0
bar_width=1
bar_spacing=0
lower_cutoff_freq=0
sensitivity=100
autosens=0
[smoothing]
noise_reduction=0

Here's the wpctl:

> wpctl inspect 701
id 701, type PipeWire:Interface:Client
    application.language = "en_DK.UTF-8"
  * application.name = "cava"
    application.process.binary = "cava"
    application.process.host = "Pallas"
    application.process.id = "126923"
    application.process.session-id = "1"
    application.process.user = "pallaswept"
    channelmix.disable = "false"
    channelmix.fc-cutoff = "48000"
    channelmix.hilbert-taps = "0"
    channelmix.lfe-cutoff = "1000"
    channelmix.mix-lfe = "true"
    channelmix.normalize = "true"
    channelmix.rear-delay = "0.0"
    channelmix.stereo-widen = "0.0"
    channelmix.upmix = "true"
    channelmix.upmix-method = "simple"
    clock.power-of-two-quantum = "true"
    core.name = "pipewire-pallaswept-126923"
    core.version = "1.5.0"
    cpu.max-align = "32"
    default.clock.max-quantum = "2048"
    default.clock.min-quantum = "128"
    default.clock.quantum = "256"
    default.clock.quantum-floor = "128"
    default.clock.quantum-limit = "8192"
    default.clock.rate = "48000"
    default.video.height = "1440"
    default.video.rate.denom = "1"
    default.video.rate.num = "60"
    default.video.width = "2560"
    link.max-buffers = "64"
    log.level = "0"
    media.category = "Capture"
    media.class = "Stream/Input/Audio"
    media.name = "cava"
    media.role = "Music"
    media.type = "Audio"
    mem.allow-mlock = "true"
    mem.warn-mlock = "false"
  * module.id = "2"
    node.autoconnect = "true"
    node.latency = "512/48000"
    node.name = "cava"
    node.passive = "true"
    node.virtual = "true"
    node.want-driver = "true"
  * object.serial = "1344"
  * pipewire.access = "unrestricted"
  * pipewire.protocol = "protocol-native"
  * pipewire.sec.gid = "1000"
  * pipewire.sec.label = "unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023"
  * pipewire.sec.pid = "126923"
  * pipewire.sec.socket = "pipewire-0"
  * pipewire.sec.uid = "1000"
    settings.check-quantum = "false"
    settings.check-rate = "false"
    stream.capture.sink = "true"
    stream.dont-remix = "false"
    stream.is-live = "true"
    window.x11.display = ":0"

> wpctl inspect 695
id 695, type PipeWire:Interface:Node
    adapt.follower.spa-node = ""
    channelmix.disable = "false"
    channelmix.fc-cutoff = "48000"
    channelmix.hilbert-taps = "0"
    channelmix.lfe-cutoff = "1000"
    channelmix.mix-lfe = "true"
    channelmix.normalize = "true"
    channelmix.rear-delay = "0.0"
    channelmix.stereo-widen = "0.0"
    channelmix.upmix = "true"
    channelmix.upmix-method = "simple"
  * client.id = "701"
    clock.quantum-limit = "8192"
  * factory.id = "9"
    library.name = "audioconvert/libspa-audioconvert"
  * media.category = "Capture"
  * media.class = "Stream/Input/Audio"
    media.name = "cava"
  * media.role = "Music"
  * media.type = "Audio"
    node.autoconnect = "true"
    node.driver-id = "177"
    node.latency = "512/48000"
    node.loop.name = "data-loop.0"
  * node.name = "cava"
    node.passive = "true"
    node.virtual = "true"
    node.want-driver = "true"
    object.register = "false"
  * object.serial = "1345"
    port.group = "stream.0"
    stream.capture.sink = "true"
    stream.dont-remix = "false"
    stream.is-live = "true"

As soon as I tried this again I couldn't reproduce it at first, but I realised it's really dependent on the bar count (and the frequency of the content):

Screencast_20250811_064337.webm

That example is with the tone generator so it's not really representative, but this is a youtube video with normal speech narration, plus the tone at 3100Hz:

(the big spikes are the tone generator, the three little bumps are the guy talking)

But if I make it smaller (less bars) the speech is totally lost, and only the tone is left (but very low bars for 100% volume tone):

Basically if I 'slide' the sound through the bars, or slide the bars around the sound, the bar height goes up and down as I slide.

I was just comparing these test settings to the default settings, and I noticed that the noise_reduction setting has a really strong effect on this. Maybe that's a hint?

Anyway thanks for your help!

[karlstav]

having noise reduction at 0 is not really something i tested a lot for. It will affect the max total height that the bars can achieve. Actually this setting should not really be exposed at all, not in it's current state at least I think I exposed it mostly for my own development purposes.

[pallaswept]

Huh, that's interesting. It seems like the problem I'm seeing is really always present, but the noise_reduction increases the amplitude a lot, and then autosens reduces the bar height accordingly, so the problem is not so visible with those two on... but if I look again, I can see it. Here's a video where I sweep the test tone and just change the noise_reduction

Screencast_20250812_023632.webm

To confirm this I played with it a little and (with the same window size as above) these two settings (toggling between sensitivity = 25 and noise_reduction=0):

[general]
bars=0
bar_width=1
bar_spacing=0
lower_cutoff_freq=0
# sensitivity=25
autosens=0
[smoothing]
noise_reduction=0

[general]
bars=0
bar_width=1
bar_spacing=0
lower_cutoff_freq=0
sensitivity=25
autosens=0
[smoothing]
# noise_reduction=0

These are basically the same, but with/without 'trails' behind the bars :) So it seems like noise_reduction's effect on this issue is 4*bar height, but the issue is still there.

[karlstav]

hi @pallaswept,

this back and forth is really useful.

It just dawned on me that the reason I made the separate buffers in the first place was just to get the lowest bass frequencies. The mid/treble was never an issue. So I thought, why not just drop the treble buffer all together and use the mid for all except sub 100Hz? It looks really promising. No more brake around the 500Hz mark, trebles are just as good. Reduced default noise reduction a bit as larger buffers is its own noise reduction. I think that the tiny buffer that I used for the treble buffers was too tiny to be useful.

Pushed the changes to the new branch now, feel free to test it.

[pallaswept]

Thanks for saying that mate, I do get nervous that I'm being annoying!

On that note, I wanted to do something more productive and with some thanks to the fact that I also have a bug right now (the biological kind 😆 ) I did spend some time working with this. I hope that's OK, I do understand that a project like this is 20% math and 80% JFM that is evolved over time and effort and trial and error, all of which I am ignorant to, so I don't know how much I can contribute... but I wanted to try.

While I was at it, I noticed other interesting behaviours (after the 'slope' upward in bar height with increasing frequency, the 'glitch' between the FFTs, and the 'jump' at 5khz):
The 0th bar is always 0.
The frequency distribution is very bass-heavy

It was immediately apparent with the new build that you have fixed the 'glitch' between the FFTs (nice!). So, my first port of call was to look at that 'slope' that originally bothered me. Turns out it's definitely that EQ. If I just bypass it and scale the "huge" values down (they're huge!) then I got a nice flat response from the bars. The bass buffer was 2x volume (I do not know why yet) so I also just divided that in half, everything worked great - the 0th bar was active, the bar height was constant across different frequencies, and the transition between the bass and mid/treble buffer was still invisible.

It wasn't all roses though... With the new 2-buffer change you've made, the 'jump' at about 5000hz now occurs at about 1500Hz - and the above bypassing the EQ, fails to keep things level after that point, with the bar height growing exponentially. I can also see the same thing in the build with the EQ, so this isn't an effect of the EQ being removed, I guess it's just the same thing we talked about earlier.

To add to this, I found that when I shrunk the window down from the 360 character width I was testing (full width on 1440p) the 'jump' was now way lower, like at 80n characters (40 bars per channel) it was at 140Hz.

Regardless of the width of the terminal and where the 'jump' happens, I see the same: Below the jump, no EQ is nice and flat, above the jump, with EQ is nice and flat; vice-versa it is not flat but sloped heavily. So it seems like we want the EQ only above the 'jump'.

So yeh, it seems like if we could just fix the handling of frequencies above that 'jump', and remove the EQ, (or maybe, use the EQ only to fix the jump, but not below it) then it would behave perfectly.

I tested all this with noise reduction all the way down (it makes it a bit tough to slide the tine generator around cleanly) but I did confirm that n_r is essentially just amplifying all the bars, and the underlying issues I'm looking at are there either way n_r is set, it's just easier to see the issues with n_r off.

In case you'd like to reproduce on your end, this is what I have so far - I only modified the right channel, so I had a good comparison, here's the config I used and the tiny test patch:

[general]
bars=0
bar_width=1
bar_spacing=0
lower_cutoff_freq=1
# higher_cutoff_freq = 15000
sensitivity=100
autosens=0
[smoothing]
noise_reduction=1

--- cava-frequency.orig/cavacore.c
+++ cava-frequency/cavacore.c
@@ -407,7 +407,12 @@ void cava_execute(double *cava_in, int new_samples, double *cava_out, struct cav
         cava_out[n] = temp_l;
 
         if (p->audio_channels == 2) {
-            temp_r *= p->eq[n];
+            // temp_r *= p->eq[n];
+            temp_r /= pow(2,25);
+            if (n < p->bass_cut_off_bar) {
+                temp_r /= 2;
+            }
+
             cava_out[n + p->number_of_bars] = temp_r;
         }
     }

This sets the bar height on the right side to about half the value it should be, just so I have some headroom while I'm testing. Easy to double it later when I know that the top isn't reaching beyond my terminal to the moon :D

Quick video to show the flat response below the jump without EQ (right side), the missing 0th bar (left side), the flat response above the jump with EQ (left side), and the moving jump depending on bar count (both sides)
(top terminal tab, frequency branch on the left, my mod on the right).
Also for comparison, the previous frequency branch build, with the three FFT buffers, showing the bar distribution difference with the two buffers (bottom terminal tab).

Screencast_20250815_162011.webm

Hopefully this is useful.

[karlstav]

no problem, I think we are more less at ways ends here, let me try to explain what you are seeing real quick:

The 0th bar is always 0.

if setting lower_cutoff_freq to below 5 the first bar starts at 0Hz (and goes to 5Hz). This caused a multiply by 0 bug, fixing now.

The frequency distribution is very bass-heavy

if setting lower_cutoff_freq to 1, as you have, you will get a lot of bars around the bass. This is because I wrote it to be logarithmic, because that is how we hear frequencies, but our ears starts at 20Hz, I set the default to 50 as there is not much we distinguish in music between 20 and 50.

that 'slope' that originally bothered me.

This program is not intended for scientific use. It's written to look responsive and aesthetic when used to visualize music. With a flat frequency response you will only see the bass when visualizing music. With cava, playing single tone at one frequency will simply not give you the same bar height as a tone on another frequency, I could add an option for this, but I don't see the point, there are better tools for that exercise.

the 'jump' at about 5000hz now occurs at about 1500Hz

as I tried to explain earlier, this is by design. The frequency of the bars in cava are distributed exponentially. If it wasn't you would only see the treble, for example if there where one bar for 0-1000Hz and one bar for 9000-10000Hz, there would only be a single bar for all bass and mid tones in the music, not very interesting. However the output that i get from the FFT is linear, I get one value for 50 to 60Hz and one value for 9990 to 10000Hz. With a lot of bars there will at some point be a 'jump' this is where one bar starts representing a broader span of bandwidth (20Hz instead of 10, typically), a single tone will then occupy a relatively narrower part of the band. We could amplify the output in these wider bands, BUT If there where to be lots of different frequencies in one band, we would have the opposite problem, it would appear louder in a broader band than in a narrow band.

[pallaswept]

Thanks for that Karl!

With that advice I had a play around and came up with something that's working really well here. I tried to follow your lead (I think it's a good idea to focus primarily on aesthetics, and I don't intend to change cava's design goals!) and did a lot of trial and error, so there are a few small changes.

I'm not crazy glued to any of this, it's just the results of some experiments and playing around, but it seems to be working really well so I thought you might like to give me a sanity check. I'll explain the changes in brief: (but perhaps it would be better for me to put this on github? I'm not sure yet, if it is useful to you)

• bass_cut_off - (personal taste/functional) I noticed that this was distorting the frequency:distance ratio in the centre, which could be nice if someone wants the bass zoomed in, but is kinda not very musical (my ears hear one octave higher and my brain knows it should be twice as far, and then sometimes, it isn't. it's really apparent with sounds that sweep through the border). If I just remove it (actually, set the cutoff to 1 for my experiments), everything still works fine, but an even better method I used was to just set it to 1000 so it's on the log10 division and still appears musically correct, and also, stops the 'jump' issue from happening (or really, it defines where it happens).
• p-eq[n] initialiser - (personal taste/aesthetics) I changed this a tiny bit from your recent commit, and I compensate for that further down with p->eq[n] *= pow((number_of_bars / (n + 1)), 0.05); which is a strictly-aesthetic tiny little bass boost. I've been throwing well-produced random genre songs from youtube at it for four hours and it just always looks better with the lower bars a little higher like this.
• normaliser for eq - (functional) - Doesn't need to be so high now that we have :
• scale bars by buffer size - (functional) The bass buffer was double the level it should be, at its cutoff. Rather than scaling the bars by log2(buffer size) (aka 12 and 13) I just scaled them by (buffer size) (aka one is twice the size of the other)
• comments - (cleanup) I think these snuck in by accident? Or maybe you were also trying what I tried here? (looks similar)
• max (not add up) FFT values - (functional) To solve the 'jump', rather than adding each fft band together, I tried averaging them, but that had the exact problem you mentioned above of course, so instead I tried a 'max() function' since it doesn't really need to be 'accurate', just show us what's in the bar. Works nicely I think?

With all these together, I think I've solved :

• bars too low (bars on a song at -0.3db are just touching the top of the terminal window)
• bars heights shrink with window width (bar heights are now constant regardless of bar count)
• bass-heavy distribution (follows log curve, if bass cut off is at 1 or 1000) (maybe it would be nice to have a setting for that?)
• 'jump' when bandwidth increases (handled by new EQ, but also controlled by moving bass cutoff)
• autosens is required (works either way now)
• smoothnig is required (works either way now)

Here's the diff, I hope you'll like the results. It looks good from my testing... but I do know that this is likely to have hidden traps for noobs like me, so if I have screwed up, I won't be offended if you point it out :) It's not scientifically correct but it is visually correct (appears scientifically correct unless you look too close haha) while remaining attractive to look at.

 {cava-frequency.orig => cava-frequency}/cavacore.c | 51 +++++++++-------------
 1 file changed, 20 insertions(+), 31 deletions(-)

diff --git cava-frequency.orig/cavacore.c cava-frequency/cavacore.c
index 0872425..9232524 100644
--- cava-frequency.orig/cavacore.c
+++ cava-frequency/cavacore.c
@@ -178,7 +178,7 @@ struct cava_plan *cava_init(int number_of_bars, unsigned int rate, int channels,
     // process: calculate cutoff frequencies and eq
     int lower_cut_off = low_cut_off;
     int upper_cut_off = high_cut_off;
-    int bass_cut_off = 100;
+    int bass_cut_off = 1000;
 
     // calculate frequency constant (used to distribute bars across the frequency band)
     double frequency_constant = log10((float)lower_cut_off / (float)upper_cut_off) /
@@ -278,37 +278,19 @@ struct cava_plan *cava_init(int number_of_bars, unsigned int rate, int channels,
         p->cut_off_frequency[n] = relative_cut_off[n] * ((float)p->rate / 2);
     }
     for (int n = 0; n < p->number_of_bars; n++) {
-        p->eq[n] = pow(p->cut_off_frequency[n], 1);
+        p->eq[n] = pow(p->cut_off_frequency[n + 1], 0.75);
 
         // the numbers that come out of the FFT are verry high
         // the EQ is used to "normalize" them by dividing with this very huge number
-        p->eq[n] /= pow(2, 29);
+        p->eq[n] /= pow(2, 15);
 
-        if (n < p->bass_cut_off_bar) {
-            p->eq[n] /= log2(p->FFTbassbufferSize);
-        } else {
-            p->eq[n] /= log2(p->FFTbufferSize);
-        }
+        p->eq[n] *= pow((number_of_bars / (n + 1)), 0.05);
 
-        p->eq[n] /= p->FFTbuffer_upper_cut_off[n] - p->FFTbuffer_lower_cut_off[n] + 1;
-        if (n < p->number_of_bars - 1) {
-            //  p->eq[n] *= pow(p->cut_off_frequency[n + 1] - p->cut_off_frequency[n], 0.5);
-        } else {
-            //  p->eq[n] *= pow(upper_cut_off - p->cut_off_frequency[n], 0.5);
-        }
-
-        /*
-        if (n <= p->bass_cut_off_bar) {
-            p->eq[n] *= pow(p->FFTbuffer_upper_cut_off[n] / (double)p->FFTbassbufferSize, 0.5);
-        } else if (n > p->bass_cut_off_bar && n <= p->treble_cut_off_bar) {
-            p->eq[n] *= pow(p->FFTbuffer_upper_cut_off[n] / (double)p->FFTmidbufferSize, 0.5);
+        if (n < p->bass_cut_off_bar) {
+            p->eq[n] /= p->FFTbassbufferSize;
         } else {
-            p->eq[n] *= pow(p->FFTbuffer_upper_cut_off[n] / (double)p->FFTtreblebufferSize, 0.5);
+            p->eq[n] /= p->FFTbufferSize;
         }
-        printf("Bar %d: Lower cut off: %d, Upper cut off: %d, Cut off frequency: %.2f, bar buffer: "
-               "%d eq: %.10f\n",
-               n, p->FFTbuffer_lower_cut_off[n], p->FFTbuffer_upper_cut_off[n],
-               p->cut_off_frequency[n], p->bass_cut_off_bar, p->eq[n]);*/
     }
     free(relative_cut_off);
     return p;
@@ -386,19 +368,26 @@ void cava_execute(double *cava_in, int new_samples, double *cava_out, struct cav
 
         double temp_l = 0;
         double temp_r = 0;
+        double nextbin;
 
         // process: add upp FFT values within bands
         for (int i = p->FFTbuffer_lower_cut_off[n]; i <= p->FFTbuffer_upper_cut_off[n]; i++) {
 
             if (n < p->bass_cut_off_bar) {
-                temp_l += hypot(p->out_bass_l[i][0], p->out_bass_l[i][1]);
-                if (p->audio_channels == 2)
-                    temp_r += hypot(p->out_bass_r[i][0], p->out_bass_r[i][1]);
+                nextbin = hypot(p->out_bass_l[i][0], p->out_bass_l[i][1]);
+                temp_l = (nextbin > temp_l) ? nextbin : temp_l;
+                if (p->audio_channels == 2) {
+                    nextbin = hypot(p->out_bass_r[i][0], p->out_bass_r[i][1]);
+                    temp_r = (nextbin > temp_r) ? nextbin : temp_r;
+                }
 
             } else {
-                temp_l += hypot(p->out_l[i][0], p->out_l[i][1]);
-                if (p->audio_channels == 2)
-                    temp_r += hypot(p->out_r[i][0], p->out_r[i][1]);
+                nextbin = hypot(p->out_l[i][0], p->out_l[i][1]);
+                temp_l = (nextbin > temp_l) ? nextbin : temp_l;
+                if (p->audio_channels == 2) {
+                    nextbin = hypot(p->out_r[i][0], p->out_r[i][1]);
+                    temp_r = (nextbin > temp_r) ? nextbin : temp_r;
+                }
             }
         }