Audio Input Level too Low

[sandinak]

+1 on a boost or trim adjustment..
+1 on level marks for settings .. would help alot.

with the standard audio output on the Mac.. I am also in the 5-15% at full blast. I havn't tried on my pi's yet .. but that's coming.

[andres robles]

Hello, I can think of some solutions, I do not know if it's valid in windows or mac, in Linux it probably works,
The solution would be to interpose a plugin amplifier between microphone and qlc ..
example of use in linux
I open jack, I open audacity, I open QLC +, and I open some plugin amplifier, (calf plugin ... or another)
in jack connect, from micro to audacity, Ready
from micro to plugin amplifier and from plugin amplifier to pulseaudio
I say in configuration of I put audio that qlc take the sound of qjack
Adjust desired volume for QLC +
Ready
I do not know if in Windows it works qjack or there are tools for the routing of audio connections so that you can interpose plugin between different audio input software to be able to adjust independent volumes to each software from the same micro, I do not know if I explain and I hope that will help you find some effective solution
a greeting

[BillDoE]

I'm having the same issue in Win 10 QLC 1.12.2 GIT. All my levels are cranked but QLC Audio input level hits about 25% tops.
Using Foobar2000 cranked through VB Audio Virtual Cable. I even tried making an amplifier with Purr Data.
My Audio gets so loud Its distorted but qlcplus audio level moves up like 2%.

[BillDoE]

I've tried this now with.
Raspberry Pi4 or Windows 10 x64
qlc 4.12.2 IMG
& 2 different external USB sound cards.
Focusrite Scarlett 2i2.
or E-MU.
Recording levels in Audacity are peaking at 100% on the same Pi machine using the same settup.

I get 100% Audio levels on the sound cards from the mixing board and the levels top out at 55% in QLC+.
Sure would like to solve this!

[BillDoE]

Using a Focusrite Scarlett 2i2 (Gen 1) usb card and XLR inputs on raspberry pi4.
I have no idea what the actual problem is, but this seems to solve my issue for now.

On my Raspberry pi4. I was stuck at 50% Peak in QLC+
I changed pwerSum to (pwrSum * 2) on line 229 in audiocapture.cpp and recompiled.

Code: Select all

229   m_signalPower = (pwrSum * 2) / m_captureSize;

I'm getting good peaks with better dynaminc range.

I do not claim to know what I'm doing. Use at your own risk.

[richard]

I bought a Movo MC1000 Conference USB Microphone that has a 20 foot range pickup for $50 US from Amazon that solved my input level problems on my Windows 10 PC. I too was having the same issues as everyone else. I did turn up the sensitivity in Windows on the mic to 100% and it's working great with QLC to the point I need to turn down the sensitivity control on the QLC sound widget. It works well for conferences when I need it as well!

[edogawa]

I tried the power_sum*2 thing and it improved things, but then again I also thought we're looking for peaks, not average power in the main volume and bands.

As this is such a long-standing issue and I was hit by it myself a year ago when I needed it, I thought I'd go over to freenode IRC channel #lad (linux audio developers) and ask for an extra eye (having no notable fft or c++ knowledge myself).

I pointed them to this thread and damo22 (Damien Zammit, developer of the Zam audio plugin suite) answered this:

<damo22> edo_lap: i had a quick look, i *think* he is calculating the power spectrum wrong
<damo22> i think he needs to take the average of the transformed values, not the raw signal
<damo22> edo_lap: i think you need to modify the AudioCapture::fillBandsData() function to compute the average as well as the maximum and return both
<damo22> and dont use pwrSum because its wrong

I doubt though to be able to implement the change he proposes... so I hope this makes sense to Massimo or whoever can code well enough, and helps to resolve the issue.

[GGGss]

3 years or so ago - I came to the same conclusion.
The math behind the audio levels is off (not wrong).
Massimo pointed me to 2, 3 related articles defending his programming decisions.
I thanked him pointing these to me and went for another solution.

[edogawa]

Damien seems to cook up something for us:
https://github.com/mcallegari/qlcplus/c ... io:fix-fft

[mcallegari]

QLC+ can surely use the help of an audio expert.
However I think I've seen an error in the change he made. He's ignoring the number of bars the user wants.

[edogawa]

Here's what he said when he pointed me to his code yesterday (I had kept the laptop and quassel chat window open to catch any messages while at work, he lives n Australia so it's a bit difficult to find a time of day to talk live during my working week):

<damo22> edo_lap: i pushed a fix that is slightly better in terms of what the bars are doing, but its still broken
<damo22> as in theres something underlying about the bar graph that i dont understand such as its scaling or how to plot it correctly
<damo22> it seems to be computing a lot of bars redundantly, but every time i try to simplify it, it breaks
<damo22> edo_lap: https://github.com/zamaudio/qlcplus is my fork with the patch

[edogawa]

Earlier today damo22 and I met on IRC and worked on this again and I think (after testing a while) with today's changes the issue is resolved from a user's point of view.

Bar levels look ok now for mono and stereo sources (tested with jack in linux), and the triggers do what I expect them to do.

[mlohrey]

I would be interested in testing this on MAC OSX.

I did some testing awhile a back (changed the pwrSum variable to 10*pwrsum to get decent levels on my mac) with some 'pure' sine waves as audio sources to see whether the fourier transform was working correctly and got very mixed results.

I would like to do the same test with your code changes.

I am not great navigating GITHUB. If you don't mind, can you point me in the direction of the code? I think I can mange the compiling part.

Cheers
Mark

[edogawa]

Here are some possibilities how to get the patch:

1. Clone damo's fork https://github.com/zamaudio/qlcplus/tree/master to a new directory, checkout his working branch fix-fft and compile as usual.

Code: Select all

git clone https://github.com/zamaudio/qlcplus.git
cd qlcplus							# go to the root dir of your working copy
git checkout fix-fft
...

This way you'll end up with a second code tree, probably not what you want...

So you may prefer

2. Update your working copy, download and apply the diff I've appended to this post, like this:

Code: Select all

cd qlcplus							# go to the root dir of your working copy
git pull							# optional, update your local codebase to obtain latest changes from main github repo
patch -p1 < ../qlcplus-audiocapture.diff			# adapt path to where you actually saved the diff

This should give you just damo's changes on top of your working copy,

HTH

EDIT: 11:45 CEST, I just replaced the diff with the latest version from a few minutes ago

[edogawa]

damo continues working on it in this moment, he's not happy yet, somehow he cannot find out how the audio channel data is interleaved if stereo... I cannot help him there, but in the meantime have made a short screencast to show the current state, I've added a jaaa window with similar frequency range to compare:

https://www.dropbox.com/s/5zuukcy5e6so7 ... .webm?dl=0

EDIT: 12:02 CEST, I also replaced the screencast link above to show the most current version of the patch
With this latest change this should be ready for merging, damo thinks the fix is complete now, and renamed the PR accordingly.

I attach the corresponding workspace so you can see what mode and channels I used on which bands...

[mlohrey]

Thanks for the info.

I have compiled a versions for MACOSX and it seems to be working.

I will do a bit more testing tomorrow when I can find a quiet space.

[damo22]

mlohrey:

Please see updated patch.

I found a bug in my changes and fixed it.
What you were testing was severely rounded to a coarse limit due to integer rounding.

This should be much better and applies to the latest master branch:

https://patch-diff.githubusercontent.co ... /1212.diff

Damien

[mlohrey]

HI Damien,

Thanks for the that.

It looks to be working really effectively. Levels are great and easy to adjust.

I generated a number of pure sine waves over a range of frequencies and the widget set to the 32 divisions (the max number of bars apparently). It was really accurate.

Now to try it with some lights!

Cheers

Mark

[GGGss]

This would need a tone function generator coupled to the line input and do a sine sweep over 40Hz to 5kHz.
This should be seen reflected in the different bars. The bars should overlap, but not that much (depending to the frequency on the input, the signal should overlap 2 bars or stay within 1 bar (bandwidth of 1 bar).

Now if the sine tone changes to triangle, the fluent going from one bar to another, should be very abrupt now. (Harmonics induced by the triangle signal).
Last test: pink-noise -> now all bars should react, showing the same level over all the bars. (Differences will show the quality of your AD-converter inside your computer)

I'm willing to test with the new source code.
If working this would mean a long-standing problem with QLC+ is solved. Cheers to that.

[edogawa]

Damien tested with a sine sweep, and so did I.

I even made an updated screencast using the latest version of the patch, but forgot to post it here, although it's using only 10 bars. I've tried with 32 bars too, and it shows just what you expect, a much smaller level in the neighbouring bands in the lower frequency area, for higher frequencies single bars.

The sine sweep comes from an LV2 plugin by Robin Gareus/x42, it has a few fixed test signal presets, and the sweep cannot be adjusted to stop at 5kHz, so the last part of the sweep just does nothing in the widget, obviously.

I put it on YT and embed it here (instead of linking to my dropbox like before...)



I've also tested with different music and it surely reacts very precisely to frequency content as far as I can tell.