Sensitivity/Gain Multiplier needed

[scruloose]

I'm using the projectM-pulseaudio implementation in Debian (v 2.1.0), and it mostly works! It is picking up the audio signal, but only very faintly. Visualizations that show a waveform are not flat-lined, but the amplitude is teeny. So instead of an exciting dancing waveform, it's a nearly-flat line with minor tremors.

I have searched the web, the GUI options, and the config file; if there's a parameter for this already, it's well hidden. Turning the gain up to 150 on the projectM "recording" sink in pulseaudio helps some. I can get it to a reasonably responsive level by also turning the "playback" source up to at least 100%, though I then have to keep my sound card's output volume ridiculously low (which requires setting "flat-folumes = no" in pulseaudio's daemon.conf).

All in all it's an ugly workaround, and it seems to me that the right solution would be for projectM to accept a gain multiplier parameter and then internally apply that to the incoming audio stream.

[revmischa]

It's a fair point. There is a parameter mapped to "beatSensitivity" in the config called something weird. I am unsure what it does but maybe it does what you want config.add("Hard Cut Sensitivity", settings.beatSensitivity); https://github.com/projectM-visualizer/projectm/blob/master/src/libprojectM/projectM.cpp#L154

[scruloose]

Hi Mischa, thanks for your quick reply!

I have played around with the Beat Sensitivity parameter a little, and I'm reasonably sure it's a different thing. I'm not much of a coder and I haven't delved into the projectM source or anything, but based on the visible results, it seems that projectM does "beat detection", so some visualizations execute various transformations (eg a fast zoom or pan) in time to the beat. If I turn Beat Sensitivity way up, then every guitar strum and every "p" or "t" in the vocals registers as a beat, triggering those transformations much more frequently. It does not appear to have any effect on the waveform animations themselves, though.

As a side-note: the beat detection (including adjustment of beat sensitivity) seems to work just fine even when the signal reaching projectM is so faint it barely registers on the waveform animations.

[revmischa]

If you really want to get to the heart of the matter you would look at the specific presets, because they decide how much weight to give the low/mid/treb amplitude. it may be being scaled by the preset, or maybe there is something general in the code

[scruloose]

All presets that feature an obvious rendering of the waveform seem to be affected to about the same degree. So while yes, theoretically one might be able to go in and rewrite them all to compensate with their individual weightings, I think a far more reasonable approach would be for the projectM code itself to implement a general multiplier to apply to the entire audio stream--or, if one already exists in the code somewhere, expose it to the user as a configurable option.

Ultimately, it would be cool to have some sort of smart auto-scaling option as well, though obviously that would be harder to implement. (Maybe something like this: take a several-seconds rolling average of the amplitude across the whole frequency range, see where that rolling average falls on a scale between flat-line and clipping, and tweak the gain multiplier up or down accordingly.)

For reference, my library of presets is exactly what was installed by the projectm-pulseaudio deb package; I have not added, removed, or modified any.

[revmischa]

Yeah I hear you. Maybe someone can dig in the code and see if there is already some scaler.

[mbellew]

bass,mid,treb (and _att variants) are all scaled by a historical volume in BeatDetect.cpp. I believe the raw PCM data which is used to render waves is used raw, and the scale can vary wildly. I wonder if it would be possible to just divide the PCM by beat_detect.vol_history when it is fetched for rendering. see Waveform::Draw()

[mbellew]

Does the check in on this branch https://github.com/projectM-visualizer/projectm/tree/waveform_autoscale seem to resolve the issue? I'm not positive about the scale, but it seems to adjust itself so it's not so sensitive to the application volume setting.

[scruloose]

That sounds promising indeed! I'll take a stab at building from that branch and see how it goes.

[mbellew]

Hi @scruloose, I just realized that my commit has been "stuck" in my local repository this whole time. I just actually pushed it. I apologize for any wasted time.

@revmischa would you review as well?

[revmischa]

Open a PR?

[scruloose]

I'm happy to report that in current release (3.1.1-rc6), on the same system as before, I now get appropriately scaled waveform visuals without having to resort to any weird pulseaudio volume-control contortions. I assume it was fixed by PR 175, though I haven't done any before/after testing to be sure.

I'll close this, as my issue is resolved.