Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_vis_vumeter (Read 276649 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foo_vis_vumeter

Reply #525 –
Quote from: boxerfan88 on
Let me re-check why my 2.1 VU is showing lower value compared with my 2.0 VU. Hmm....

Hmm ... does the info below explain why my 2.1 VU is showing lower than 2.0 VU ...?

Quote from: ChatGPT
That's correct! If you mix down from **L+R to C** and then attempt to upmix from **C to L+R**, you **won't get back the original level**. Here's why:

### Mixing down L+R to C:
When you mix down the left (L) and right (R) channels to the center (C) using the formula:
\[
C = \frac{L + R}{2}
\]
You're averaging the two channels, which means the center channel (C) will have less energy than the sum of L and R. Specifically, if the left and right channels are at the same level, the center channel will have 6 dB less power than the original L+R sum because you're averaging the signal.

### Upmixing from C to L+R:
When you try to upmix from C to L+R with:
\[
L = C \times 0.5
\]
\[
R = C \times 0.5
\]
You're simply splitting the center signal evenly between the left and right channels. Since you averaged the L+R to create C initially, you're now redistributing that average back into the left and right channels, which results in a signal that’s at a lower level than the original L+R mix.

### Why this happens:
- **Loss in level during mixdown**: When you mix down L+R to C, you average the two channels, which results in a lower overall level.
- **Loss in level during upmix**: When you upmix C to L+R, you're redistributing the lower-level center signal back into both channels.

### The result:
When you mix down L+R to C and then upmix from C to L+R, you'll have a **reduced level** compared to the original L+R mix. Specifically, the upmixed signal will be approximately **6 dB quieter** than the original, assuming you used the simple upmixing formula (with equal distribution).

### How to avoid this:
If you need to preserve the original levels, you could modify the upmixing formula by compensating for the loss. For example, you could use:
\[
L = C \times \sqrt{2}
\]
\[
R = C \times \sqrt{2}
\]
This would restore the signal to its original level when upmixing. However, this might result in a slight imbalance depending on the exact method used for mixing down.

In practice, the exact compensation method can depend on the specific application and desired result, but the general rule is: **mixing down L+R to C reduces the level, and upmixing doesn't fully recover it unless you apply some compensation.**

Re: foo_vis_vumeter

Reply #526 –
Quote from: boxerfan88 on
Let me re-check why my 2.1 VU is showing lower value compared with my 2.0 VU. Hmm....
Check your set up. Turn off all active DSP (Digital Signal Processing) in the foobar2000 preferences.
Reset VU meter tune and select your desired level mode. Using peak is easiest.
Check your test tones or create your own so you know exactly what is on each channel. Using a single-frequency sinusoidal tone is easiest. You can use Audacity.

If you know the amplitude of the signal on each channel going in, based on the mode you select for the VU meter and the mix factors. You should be able to predict where the needle will appear.

Mathematics aside: linear multiplication in a logarithmic scale is simple addition. So, a signal at 0dB with a mix factor of -3dB will appear at -3dB. The samples in foobar2000 64-bit are float64 in the linear scale range of -1.0 to +1.0, and we assume it to be a voltage ratio. To convert to linear scale from logarithmic scale use x=10^(y/20) and in the reverse y=20*log10(x).

Re: foo_vis_vumeter

Reply #527 –
Another minor release: 0.10.11
Mostly maintenance and optimization updates. Once again, it is not set to auto-upgrade due to insufficient testing.

Re: foo_vis_vumeter

Reply #528 –
Since I don't have a Reddit account, I'll do it here. Thank you for the kind words to whoever posted this. Happy you're having a great experience!

Re: foo_vis_vumeter

Reply #529 –
Update: 0.10.12

This one marked as "Current Release" and so should auto-update. It includes lots of updates since the last auto-update version which was 0.10.2. The list of changes is on the component releases page.

Re: foo_vis_vumeter

Reply #530 –
@oops thank you so very much for this  👍 👍 👍  😊😊😊

Re: foo_vis_vumeter

Reply #531 –
Foobar2000 v2.24.3 64-bit, Window11.

Apparent bug in 10.12:  there is no way to disable the new mixer panel;  the "enable mixer" box cannot be unchecked.  The Levels->Mixed menu choice, if not selected, still will not disable the panel--and, what has precedence over the other now in how the signal is actually processed?

Q:  What was the reason for adding a channel mixer to a VU Meter in the first place?  Apologies, but if I was in a cranky mood I would say it appears like some gimmicky extra for Dolby fans that already is causing some kind of cross-purposing with what a VU Meter's role actually is.  This is the kind of thing I was concerned about in the past, adding features that make the application less and less true to what it is meant to show until something "breaks."  Cranky mode "off." :(

Re: foo_vis_vumeter

Reply #532 –
Quote from: sveakul on
Q:  What was the reason for adding a channel mixer to a VU Meter in the first place?  Apologies, but if I was in a cranky mood I would say it appears like some gimmicky extra for Dolby fans that already is causing some kind of cross-purposing with what a VU Meter's role actually is.  This is the kind of thing I was concerned about in the past, adding features that make the application less and less true to what it is meant to show until something "breaks."  Cranky mode "off." :(

It was my feature request. Oops kindly exposed the internal mix_factors for user to tweak.

Reason why I asked for this feature request ... is because I was seeing VU level difference between 2ch (stereo) track vs. 2.1ch (post-DSP) on my setup ... I was hoping to be able to tweak the mix_factors specifically for my own use. For most users, the default mix_factors should work well, which was already inside the component code, just that it wasn't exposed for user tweaking.

In my setup, I used the foobar built-in 5.1 upmixer, which generates the Center channel from mixing LR using the formula (L+R)/2 which is already 3dB down. I use the Center channel for the subwoofer signal processing.

Hope this clarifies.


.


Re: foo_vis_vumeter

Reply #533 –
Quote from: sveakul on
Foobar2000 v2.24.3 64-bit, Window11.

Apparent bug in 10.12:  there is no way to disable the new mixer panel;  the "enable mixer" box cannot be unchecked.  The Levels->Mixed menu choice, if not selected, still will not disable the panel--and, what has precedence over the other now in how the signal is actually processed?

Q:  What was the reason for adding a channel mixer to a VU Meter in the first place?  Apologies, but if I was in a cranky mood I would say it appears like some gimmicky extra for Dolby fans that already is causing some kind of cross-purposing with what a VU Meter's role actually is.  This is the kind of thing I was concerned about in the past, adding features that make the application less and less true to what it is meant to show until something "breaks."  Cranky mode "off." :(
First of all .. I am not using this mixer.

But I am all for adding features if they are relevant for some people. When features are added bugs may be introduced.
So what? The developer will fix it and until that time you just go back to the previous version.

The attitude of please do not add features means nothing will ever change.

Re: foo_vis_vumeter

Reply #534 –
I hear you, nothing but respect for both of you.  My feeling in contrast is that adding features should be relevant to the component's "functional identity".  The idea that it's also OK if they "are relevant for some people" opens up a pretty big door.

Oops, did you get a chance to look at the "impossible-to-uncheck 'Enable mixer' bug"?  If those are the levels coded into the meter, it would be better to only have a "default" button, otherwise the impression is given that they can be taken out of the equation entirely.  Also would appreciate some comments on how the existing menu choice of "Levels" relates to/interacts with the new Mixing panel?

Re: foo_vis_vumeter

Reply #535 –
Quote from: sveakul on
Apparent bug in 10.12:  there is no way to disable the new mixer panel;  the "enable mixer" box cannot be unchecked.  The Levels->Mixed menu choice, if not selected, still will not disable the panel--and, what has precedence over the other now in how the signal is actually processed?
Quote from: sveakul on
Oops, did you get a chance to look at the "impossible-to-uncheck 'Enable mixer' bug"?  If those are the levels coded into the meter, it would be better to only have a "default" button, otherwise the impression is given that they can be taken out of the equation entirely. Also would appreciate some comments on how the existing menu choice of "Levels" relates to/interacts with the new Mixing panel?
Not a bug. It is intentional. I wanted to make it clear that it is always enabled. In Win32, graying it out (disable) removes the check mark so I preferred to leave it that way and ignore the mouse click. I've added a tool tip for the check box in the development build to make this point clear. And might require some synchronizing with the current settings (as your second question suggests). Also didn't want to leave the "default" button all alone, 'cause lonely buttons can get sad.
The "audio processing pipeline" if you can call it that goes like this:
PCM from player -> Mixer into 2 channels -> L/R or M/S assignment -> Preamplifier gain -> "Level" calculations using selected mode
Exceptions are made for the BS.1770 and R128 modes which skip the mixer as they have their own weightings for each of the 5.1 channels (which you can find in the papers).

Quote from: sveakul on
Q:  What was the reason for adding a channel mixer to a VU Meter in the first place?  Apologies, but if I was in a cranky mood I would say it appears like some gimmicky extra for Dolby fans that already is causing some kind of cross-purposing with what a VU Meter's role actually is.  This is the kind of thing I was concerned about in the past, adding features that make the application less and less true to what it is meant to show until something "breaks."  Cranky mode "off." :(
The reason is answered above. But I want to address your concerns.
I'm keenly aware that keeping ourselves pinned to specific versions this is becoming more necessary as users of the overall software ecosystem; given the large amount of unstable software due to increasing complexity, dark patterns and anti-features out there. I understand the sentiment.

Let me preface all of this by saying that this component is nothing more than fun eye candy to complement the musical experience. It is an interesting project (for me) for hobby and non-professional purposes. As such, I do take liberties that I would not take in a professional setting. You can see that in the variety of things marked as "[developer]" in the release notes. Several of those are substantially riskier to stability or introducing bugs/regressions than the mixer panel. Maybe one day someone will also question those ;)
While this component is not that complex if you were to look at it in context, it is nonetheless easy to break something. To mitigate these risks, I try to stress test the basic functionality. Part of not making the 10.5, 10.10, 10.11 releases "current" (only the current release is compared by foobar2000 for auto-update) is because of those updates. I wanted to ensure that the main/basic functionality did not degrade before I did a wide rollout. Yet still made the versions available for those (like me) that are willing to tolerate foobar2000 misbehaving temporarily in exchange for new capabilities or fixes. To borrow from our aerospace friends, the music player (for me) is Software Level E.

Quote from: boxerfan88 on
In my setup, I used the foobar built-in 5.1 upmixer, which generates the Center channel from mixing LR using the formula (L+R)/2 which is already 3dB down. I use the Center channel for the subwoofer signal processing.
Not all music is created the same way :)

Quote from: Defender on
But I am all for adding features if they are relevant for some people. When features are added bugs may be introduced.
So what? The developer will fix it and until that time you just go back to the previous version.

The attitude of please do not add features means nothing will ever change.
Quote from: sveakul on
I hear you, nothing but respect for both of you.  My feeling in contrast is that adding features should be relevant to the component's "functional identity".  The idea that it's also OK if they "are relevant for some people" opens up a pretty big door.
As you'll see below, I have a very narrow use case. Meaning if I were doing this project in isolation, it would have been "feature-complete" many months ago. And while the core identity has remained and will likely not change, its functional capabilities around the core have grown. Sometimes it'll be a thing that many people will use, others it'll be what only a few people (or no one) will. Since this project is not for pro consumers where I need to care about such things (and I will never, ever put telemetry in a component to find out), if I think it is cool I'll try to do it (up to a point).
Please know that I try very hard not to release something with a problem. Especially in existing and "mature" functionality. If the problems are in newer features, then that's less of a problem. Mostly because, judging from how things have gone, we evolve the feature set together: I put out a "draft," you tell me what works, what you like, what to tweak and then iterate on that. I know that my assurance doesn't mean much, but no user of VU meter should ever feel the need to revert to an older version. That would be a major screw up and I will try to rectify it ASAP (case in point: the corrupted settings crashes).
Lastly, while I'm actively working on it, features or whatever, then it will stay out of the graveyard of abandoned foobar2000 components.

What do I mean by basic functionality?
First my setup. I run foobar2000 x64 2.24.3 in Portable mode and with the Default UI. These are the non-standard components I have installed:
foo_dsd_processor (1.3.4), foo_external_tags (1.5.14), foo_input_ffmpeg (0.8.2), foo_input_gme (0.5.4), foo_input_sacd (1.6.3), foo_midi (2.18.0.0), foo_openmpt54 (0.7.9), foo_record (0.2.6), foo_ui_columns (3.0.0-alpha.6), foo_uie_webview (0.3.0.0-alpha2), foo_vis_goom (0.0.3-alpha0), foo_vis_midi (0.1.0.0), foo_vis_milk2 (0.3.3.0), foo_vis_spectrum_analyzer (0.8.0.0-beta2), foo_vis_vumeter (0.10.12.0), foo_wave_minibar_mod (1.2.58)

Basic functionality means:
  • All varieties of VU meters load. My test suite includes all of the basic combinations, and all of the corner cases discovered thus far. Using screensaver mode in a loop changing panel every 3 seconds.
    • BINs (LZMA, bzip2, zlib, Zstandard, LZ4, Lzlib, uncompressed, resource).
    • ZIPs with all WIC codecs and INI.
    • RARs with BIN and INI.
  • Validate audio processing using some basic test tones to see the needle movement and the LEDs.
  • Context menu logic, state machine, settings.
  • Test all buttons in dialog boxes.
  • Power scenarios like sleep, hibernate, restarting the player.
  • Long running alongside other CPU/GPU-hungry components.
  • Dark mode (simple eye test) for background, context menu and dialogs.
  • Fullscreen.
  • Embedded/non-embedded or docked; multiple instances.

What is generally not tested because it is not in my main player:
  • Columns UI functionality including transparency.
  • COM Automation.

Sorry for the information overload. I took a couple of days to make sure I get my thinking in order. As always with text-based communication, nuance is hard to get across. So, if something is not clear or translates well into your language, don't hesitate to ask.

Re: foo_vis_vumeter

Reply #536 –
oops, thanks for this "Magnum Opus".  All very clear and complete, you could have a second career as a technical handbook writer.  The only thing I take umbrage with is your comment that "this component is nothing more than fun eye candy to complement the musical experience."  Give me a break  ::) .  It's a LOT more than that, and I've seen what you describe too many times in other applications to be fooled.  Keep up the terrific work.

Re: foo_vis_vumeter

Reply #537 –
Some minor annoyances corrected in 0.10.13:
  • Add dark mode and tooltips to the mixer dialog. The screenshot shared above should now look correct in dark mode. There are also tooltips for all the channel abbreviations and the enable and default "buttons".
  • Add component icon to parent window instead of parent window class. This will fix this component's icon appearing in other windows' title bars that use the "non-docked" host window class ("{483DF8E3-09E3-40d2-BEB8-67284CE3559F}").
  • Update mixer enable behavior and its tooltip. It will check and uncheck itself to reflect the selected "Level" mode. For now, clicking on it will not actually check or uncheck it or change the selected level mode. Thought about making it a drop-down but adding yet another place/way to change the "Level" takes away from the mixer's raison d'être.
  • Add version and time zone control options to build script [developer].

Re: foo_vis_vumeter

Reply #538 –
Some more details corrected in 0.10.14:
  • Align text labels in the mixer dialog. So that it looks good in the default size and also when resizing.
  • Improve the mixer dialog's DPI-aware scaling. Speaking of, I develop on a screen that is 3840x2160 with 150% scaling. I tried to go down to 100% and make sure that the GUI and context menu look fine under those conditions as well.
  • Add space between quantity and unit in mixer dialog's decibel labels. Makes the entire component (tool tips and labels) consistent.
  • Add background color edit control to mixer dialog. For BIN panels, the background is the average color of one of the edge column/row pixels. Now you can roll your own RGB color (in hexadecimal). Does not have any effect with ZIP (AIMP/LVU) panels since for those you can just pass a "bg.png".
  • Improve context menu radio bitmap DPI awareness. Again, the context menu circle does not look good in 100% DPI scaling, this should make it better. It is a bit too small for my personal taste, but since I don't run with that scaling, I'm not making a fully-custom icon set.
  • Fix "reverting mixer factors to default" not working.
  • Use SSE and NEON intrinsics for audio scaling and peak level search. All architecture variants other than x86 (32-bit) should benefit. It makes no noticeable difference, but it is theoretically faster ;)
  • Replace `TEXT` macro [developer].
  • Normalize brace usage in control flow statements [developer]. Found several hidden bugs and inconsistencies by reading almost every line of the source code.
  • Fix mixer class formatting [developer].
  • Debug using window message tracing [developer].
  • Add foobar2000 window class GUIDs [developer].

Enjoy the noise.

Re: foo_vis_vumeter

Reply #539 –
Hi,  I don't know if it's supposed to work the same way as the old component but I installed and copied all .bin skins I had but the meters are not moving like a VU Meter at all, way too fast and jumpy even on the slower settings.  The old version was not that far from a real VU Meter movement. 

A VU meter has a very specific ballistic characteristic, that is, it responds to changing audio signals at a very precise speed, rising from no signal to 99% of 0VU when a 1kHz sine wave tone is applied for 300ms (The ballistic characteristics of the device do not permit it to accurately register transient signals shorter than 330ms).  The needle is also supposed to fall in 300ms.

Re: foo_vis_vumeter

Reply #540 –
Quote from: SkyTrax26 on
Hi,  I don't know if it's supposed to work the same way as the old component but I installed and copied all .bin skins I had but the meters are not moving like a VU Meter at all, way too fast and jumpy even on the slower settings.  The old version was not that far from a real VU Meter movement. 

A VU meter has a very specific ballistic characteristic, that is, it responds to changing audio signals at a very precise speed, rising from no signal to 99% of 0VU when a 1kHz sine wave tone is applied for 300ms (The ballistic characteristics of the device do not permit it to accurately register transient signals shorter than 330ms).  The needle is also supposed to fall in 300ms.


You need to enable the "Apply Inertia" option.  You can then try changing the decay rate after enabling the first option.  I also recommend turning cubic interpolation on if your system can handle it.
 

Re: foo_vis_vumeter

Reply #541 –
Quote from: SkyTrax26 on
Hi,  I don't know if it's supposed to work the same way as the old component but I installed and copied all .bin skins I had but the meters are not moving like a VU Meter at all, way too fast and jumpy even on the slower settings.  The old version was not that far from a real VU Meter movement.
It is only loading the BIN files created for the old component. It is not a behavioral reproduction for the reason that I'm very confident that the "old" version is not close to modeling a "real" VU meter's movement.

Quote from: SkyTrax26 on
A VU meter has a very specific ballistic characteristic, that is, it responds to changing audio signals at a very precise speed, rising from no signal to 99% of 0VU when a 1kHz sine wave tone is applied for 300ms (The ballistic characteristics of the device do not permit it to accurately register transient signals shorter than 330ms).  The needle is also supposed to fall in 300ms.
I too can also read and quote Wikipedia.

Instead of preaching please share constructive suggestions on settings of how to achieve more accuracy. There are many knobs to tweak that will give different results. You can control the window width and other parameters.

What follows below is the method I used to model the needle movement. This is my wheelhouse, if you pardon the expression, so the technical level of the conversation will be raised quite substantially. If you can do better or have suggestions on how to improve it, please share. If not, please don't add your voice to the chorus of critics in these audio forums demanding perfection.

I started with the circuit from my own stereo VU meter as pictured below. I traced the PCB and got all the component values to translate it into a SPICE netlist. I even built my own model for the NJM4565 since I couldn't find an existing version. I simulated the netlist, instrumented in the standard ways to get the step/transient and impulse responses of the "system". These will come in handy later. Keep in mind that the VU meter face plate is logarithmic and so the circuit involves analog differentiator, integrator and summer circuits. Putting an oscilloscope probe on the various points of the working circuit helps in figuring out what's going on. Fun times.

Once I had the characteristics of the driving circuit I turned my attention to the needle. The needle can be modeled as a mass-spring system. So, setting up the ODE for the system (with some minor guesses) provides the behavior characteristics of the needle. This is a common second-order system with known roots, so not much to add to it.

So, after all of the pen-and-paper prework was completed, how is it actually implemented in the component? From the response of the circuit and simply looking around at real VU meters it is obvious (in general) these are set up underdamped. What is one simple way to simulate these physical characteristics on a computer animation? A PID controller! It can be implemented in about 15 lines of C++ and uses simple arithmetic. The PID coefficients are derived from the transient and impulse response targets of the SPICE simulation as those come from the voltage levels (closest to the visualization audio levels provided by foobar2000). To make it simpler for users I abstracted out the PID coefficients into simpler numbers called "rise" and "decay"--where the larger number means faster. Also "jitter" which is a control on the minimum increment to the error accumulator.

This is the method I chose to approximate the analog behavior of the needle in a discrete simulation. If you prefer another component's behavior, use that one. Or write your own as plugin makers for other players like MusicBee have done with their own spin on the simulation methodology. Or even better yet, build or buy a real analog VU meter and plug it into your DAC!

In engineering, it is a skill to know what a good enough approximation is and where to draw the line. This was clearly not the case here ;) I honestly don't think many have and would go through the trouble. That you think other components/plugins are more accurate is an illusion; not that this component is accurate either.

I hope the takeaways here are that there is some sound reasoning (no pun intended) behind the method to how the simulation is done and that I think you can achieve the desired ballistic movement with the tuning knobs provided. But it will take time and experimentation.

Re: foo_vis_vumeter

Reply #542 –
Hi,
I have this problem: I would like to install the Defender skin (N full install), but I get a crash (runtime error).
The problem is the foo_vis_vumeter module, because if I remove it, the skin works, as well as if I remove the graphics drivers completely while keeping the aforementioned module.
I tried several old drivers, but without success:
win64_154014.4352
win64_15407.4279

extract of crash report:

Crash location:
Module: foo_uie_eslyric
Offset: FA820h
Symbol: "DllGetClassObject" (+19870h)

[11016ms] foo_vis_vumeter: Exception while creating DirectX device - CreateGraphicsPipelineState
[11016ms] foo_vis_vumeter: Could not initialize VU Meter.
[11031ms] myLibrary init
[11031ms] myInitStageCallback init
[11031ms] Library initialized after 0:11.028574

My specs:
Intel(R) Core(TM) i5-4440S CPU @ 2.80GHz
driver GPU 20.19.15.4352
MEM: 4GB
DirectX Version: DirectX 12

Any help, please?

Re: foo_vis_vumeter

Reply #544 –
Quote from: oops on
Already discussed earlier in the thread:
https://www.intel.com/content/www/us/en/support/articles/000057520/graphics.html

I would not recommend running any version of a driver with kernel access affected by known CVEs. But it's your machine.

Thanks for your reply, but it doesn't work.
I tried to intall that drivers and some older, but the problem was not solved

Re: foo_vis_vumeter

Reply #545 –
Quote from: calabuig on
Thanks for your reply, but it doesn't work.
I tried to install that drivers and some older, but the problem was not solved
Sorry, I don't have any additional insights to offer. Essentially your driver is failing to run a fundamental DirectX 12 function call. As fond as I personally am for the Haswell microarchitecture, I'm sorry to tell you that your system does not seem to support the needed baseline functionality.

Re: foo_vis_vumeter

Reply #546 –
Quote from: oops on
Quote from: calabuig on
Thanks for your reply, but it doesn't work.
I tried to install that drivers and some older, but the problem was not solved
Sorry, I don't have any additional insights to offer. Essentially your driver is failing to run a fundamental DirectX 12 function call. As fond as I personally am for the Haswell microarchitecture, I'm sorry to tell you that your system does not seem to support the needed baseline functionality.
It's not just the DX12 issue which you should be able to solve by installing the older drivers. Imo the combination with a 4GB system ram is the issue, especially since the Haswell GPU draws on system ram too.

Only one way to check, add system memory. Question is if you want to spend extra money/effort on a 2013 Q3 system with no guarantees that the issue will be solved by adding memory.
EDIT: On the other hand it is not just about fooBar. Increasing system memory from 4GB to 16GB (or even to 8GB) will improve overall current windows 10 or 11 system performance a lot.

Re: foo_vis_vumeter

Reply #547 –
Small release: 0.10.15

Spoiler (click to show/hide)

Re: foo_vis_vumeter

Reply #548 –
Quote from: Defender on
Quote from: oops on
Quote from: calabuig on
Thanks for your reply, but it doesn't work.
I tried to install that drivers and some older, but the problem was not solved
Sorry, I don't have any additional insights to offer. Essentially your driver is failing to run a fundamental DirectX 12 function call. As fond as I personally am for the Haswell microarchitecture, I'm sorry to tell you that your system does not seem to support the needed baseline functionality.
It's not just the DX12 issue which you should be able to solve by installing the older drivers. Imo the combination with a 4GB system ram is the issue, especially since the Haswell GPU draws on system ram too.

Only one way to check, add system memory. Question is if you want to spend extra money/effort on a 2013 Q3 system with no guarantees that the issue will be solved by adding memory.
EDIT: On the other hand it is not just about fooBar. Increasing system memory from 4GB to 16GB (or even to 8GB) will improve overall current windows 10 or 11 system performance a lot.

I found 4GB extra memory and I add it to my PC, so it has a total of 8GB memory.
But the skin, with the old drivers, crashes anyway!
P.S. I even try to add the new foo_vis_vumeter 0.10.15

Re: foo_vis_vumeter

Reply #549 –
Hi, Thx for this component, is there any way to stop the component/gpu usage when Foobar is minimized, it does if you put it on a tab and change tab, but would prefer to have no GPU usage if Foobar is minimized for performance.  Default UI btw ty