Gain / Input-Volume control

[jugo6]

Development question on Input-Volume Control:

Problem:
I work a lot with choirmembers who just have a headset and nothing else. It works, and often sounds still reasonably ok. However controlling the input volume is quite a hassle. (esp. In windows). Wouldn't it be nice just to have a neat input slider at the left, preferably also to +12dB? It will also be helpful to a few softer mic/interface combo's I heard of, and avoid the hassle of extra screens, interface-mixer windows etc..... Not everyone is a guitarist with a volume knob....
And using the S-word: Sonobus has it...😁😈 And every decent analog mixer controls the input.

What is further going wrong :
people expect it that much, that they start messing with the Pan or Reverb attempting to control their gain....

Solution:

• A Slider at the input- side in between L/R lights
  Possibly in another color

• possibility to increase input above 0dB (+12dB)

Alternative: a gain turning knob

Additional:
Perhaps make the Pan more intuïtive by being horizontal or also a turning knob, with "My Pan"
because up-down never feels like L/R

[ann0see]

Hi @jugo6. Thanks for your feature request!

I moved your issue from the website repo to the code repo so that others see it!

Perhaps make the Pan more intuïtive by being horizontal or also a turning knob, with "My Pan"

Although this is another issue, I think the designer team is currently thinking about this. Thanks for raising this issue!

---

Concerning the problem of loud/quiet headsets. Yes, we (my choir) also have issues like that and the choir leader mistook pan for it too (it seemed to do what he expected and didn't actually move the mix anywhere at least according to him), so in general I support your feature request and idea behind it.

The problem with adding a feature like this (= probably duplicate feature) would be, that it might be out of scope of Jamulus (not sure though) since to some extent it is possibe to control input gain via e.g. Windows.

I get your point: Inexperienced users probably don't know about this setting.

How this can be done should be documented in the Jamulus documentation and surely some kind of help should be in Jamulus. Any ideas?

The guideline suggests the "Keep it simple and stupid" approach. In my case, minimalism made it possible to onboard inexperienced users who were/might have been overwhelmed or intimidated with features from other more full-featured applications. Not that I say your feature request might result in Jamulus becoming intimidating or overwhelming people, but at least for me Jamulus was the only application who was simple enough to be understood by inexperienced users (= choir members) due to the KISS approach. That's why I support it too and might be a bit conservative ;-).

A change like this might require a lot of code changes and - once too many duplicate features are implemented - result in a cluttered UI and therefore a worse UX. Exactly the opposite to what you wanted to solve with this problem. That's why - in my opinion - we should try to solve the problem differently. I think there even was a discussion before about this issue here. Adding a slider like this might not even be possible due to some technical reasons I don't exactly remember.

Any further ideas?

[ManfredSchenk]

I support the request for a simple possibility to set the input gain, but I also understand the arguments against implementing such a slider inside Jamulus. Perhaps there might be another solution (but I don't know if it is possible since I'm not a windows developer) - my idea would be as follows: Have a UI-element labeled with "input gain" which then opens the settings-box of Windows you "screenshotted" above. If there are multiple inputs available and jamulus cannot decide which is the right one, at least some explanation window should be shown to guide the user to the right place. Unfortunetaly, I do not know if something similar would be possible for the other platforms.

[hoffie]

Not sure if you've seen the following comment: #1030 (reply in thread)

I agree that having a way to jump to the proper settings panel directly would be the best thing, usability-wise. Sadly, I think this is really hard to do, even just for one platform. I'm happy to get convinced of the opposite. :)

[jugo6]

On keeping it simple: I think windows is keeping it far from simple by having to execute at least 6 steps to reach the control, and than you still have to find the right microphone/audio in to select, which is also not error-proof I found. I made several Help documents to tackle this. I found that for some people each week their volume is different, set by other programs accessing the volume settings....

Duplicate feature: in my current setup I sometimes have 4 or more points to control my volume. I don't see that as a problem. In a normal mixer situation you set you gain up to just below clipping at mix signal, and you still have a volume slider. (However one can argue about that being the mix so the right side of Jamulus.)

Simon suggested in facebook Jamulus Official a problem might be that the sound input is different in each OS. I hope at some stage we can still "grab " the signal before going out :-)

thanks for thinking along !

[38github]

Yes, an input drive would be a great feature. I know that some people use condensor microphones that even at lowest gain on the interface is louder than the rest of the musicians. I think the user should in first hand be able to set a reasonable loudness (-23 LUFS or whatever fits others or server rules) than the others having to lower every participant with to louud volume. This is one of many features that I think Jamulus need now to it is popular and the servers are crowded with people who do not know how to setup their sound and make it hard for others to enjoy the stay in channels.

[gilgongo]

Hi All, this doesn't look like something that will be solved any time soon for a number of difficult technical reasons.

We'd also like to clear up the Issues so that it only has defined actions for the backlog. So I'm moving this to a discussion. If and when an implementable and agreed solution is found, we can raise that as a ticket an reference this discussion if need be.

[S-luap]

I had previously raised a similar request (#678) which has just been closed on the grounds that it is “ out of the scope of what Jamulus is really about (device audio issues aren't really Jamulus's responsibility)”. Perhaps my request wasn’t worded correctly, I think it may have been misinterpreted as requiring Jamulus to be able to adjust the mic sensitivity, when really the request is for Jamulus to be able to control how much of the input signal volume received from the device is sent to the server. So the user could set the device sensitivity in Windows settings to be 100%, and then have a slider control alongside the input display in Jamulus to choose how much of that would be sent from the Jamulus client to the server. So in the same way that the personal mix lets you control how much volume is coming back to you from each musician / singer, this input slider could control how much of the available input volume was sent from you to the server.

[gilgongo]

Well, I said "may well be" :-)

Happy to discuss further here of course (but the two discussions may now be duplicating...). However, I think the "80/20" rule might be worth invoking here perhaps? That is, given that this may be a bit of a minority thing, you don't want to inconvenience or confuse the majority with it. So engineering issues aside, I'd say its very much dependent on how the UI is presented. Multiple volume controls may well be a problem.

It's really part of this wider discussion about UI requirements in general I think: #1028

[jugo6]

I think I disagree on that minority thing, but I like to see that measured ;-)

Grouping is probably also a minority issue, still its incorporated with some neat key shortcuts. (still a good thing though)

A few arguments in favor have already been given. In my field i see a lot of people who expect an input knob or slider, and at first start leveling their return signal, plus several people with professional setups not getting in loud enough. With my condensor mic I'm also just hitting 1 or 2 yellow. Hidden button not to confuse your 80?

[S-luap]

I think we have a common experience. I am a member of two choruses (40+ members in each, with a third chorus just coming onstream) using Jamulus - and to great effect, it really is an amazing piece of technology that has been a game changer in terms of being able to sing and rehearse together in the current lockdown situation. And even beyond lockdown we see a place for it in running quartet / small group / sectional rehearsals without requiring lots of travelling and hiring of rehearsal rooms. (BTW we are using Jamulus alongside a private copy of a Jitsi server running in the same data centre; we use it (muted) in a browser with screen resolution throttled down to reduce total data download rates, giving a well synced visual element too).

The scenario relating to this enhancement suggestion is either “X I can hardly hear you, even if I turn you right up - you need to turn your mic up” or “X you’re red lining all the time, you need to turn your mic down”, followed by the response “I’ve turned my slider up / down - is that better?”. Of course it isn’t as they’ve moved the fader above their name in their personal mix. So you say “No, you need to alter your input level”. Back comes the reply “where do I do that in Jamulus?”. And then they have to be reminded how to navigate through multiple Windows sound settings dialogues (or audio settings on a Mac) to adjust their mic level.

Maybe there are technical reasons why it can’t be addressed in the Jamulus UI, but the user experience (especially for the less computer-literate users) is that it feels intuitively like there should be a way, in the Jamulus client interface, to modify / moderate the input signal level being sent through to the Jamulus server. In the same way that there are fader controls for each output signal being received, it would seem logical that the input signal bars would have a fader too. “Mute Myself” is a great feature for setting 0% volume, it would be nice to be able to adjust to levels in between 0 and 100% of the maximum available input volume.

[chrisrimple]

I think there are 2 distinct problems identified, but maybe a similar solution...

1. A client is too loud and needs to reduce their input gain. This can be solved by all others on the server by adjusting the fader for that client down. But an Input knob/slider in the client might be a great idea, which could adjust what is sent by the client (to the server) in the range 0-100% of input gain.

2. A client is too quiet and needs to increase their input gain. This can be solved by all others on the server by adjusting the fader for that client up, but that may still not be sufficient. An Input knob/slider in the client might be an interesting idea, which could adjust what is sent by the client (to the server) in the range of 0-150% of input gain. Yes, that means the Jamulus client would add amplitude (rather than try to control input gain in the operating system).

So basically, it's a single Input knob/slider that centers on 100% but can be adjusted 0-150% (or maybe 0-200%). Which is pretty much what was suggested originally, I think.

Now, I can't speak to the ease or difficulty of implementation, what public libraries might be available, etc. But this would definitely be a help for choruses and really anyone using Jamulus with non-technical singers/musicians.

[gilgongo]

@hoffie OK good!

So might we try something like this?

If you think that some or all of what you have described might work (and of course be worth the effort), and you or somebody else might be able to code it and do a PR for review, then please open a GitHub Issue and describe how you'd do it so that other engineers can chip in. It's also UI related to that'll need some thought as well. Or you can just do a PR and we can discuss that (but it's means it's harder to keep hold of, project management wise).

BTW Can you see the "Reference in new issue" option on this menu? If so, use that - I've not tried myself!

[hoffie]

I think it's very easy to increase/decrease loudness in the client somewhere around the reverb code.

So, any such statement should be backed by some evidence. Here's a quick PoC in case someone wants to try out: https://github.com/hoffie/jamulus/tree/autobuild/clientgain-poc-1030 (as far as I understand the autobuild, actual binaries should be produced after the jobs completed, so this should be easy to try out even on Windows?). Just start Jamulus built from this code with Jamulus --clientgain 0.5 to reduce gain by half, --clientgain 2.0 to double the input volume, etc. When adding to much gain, clipping will begin.

Note: I'm deliberately not submitting this as a PR because I'm not sure that's the right approach for tackling this issue as a whole as mentioned above.

@S-luap @38github @jugo6 Wanna try if something like this would work for you in general?

@gilgongo I will look into trying the other approach (permitting mixer levels to go above 100%). Will also try the Github feature you mentioned.

[gene96817]

I think it's very easy to increase/decrease loudness in the client somewhere around the reverb code.

I don't know how to understand the impact of this. However, "reverb" is a hot button for me. Reverb is very bad for barbershop.

[hoffie]

I have successfully tested this with a member of my choir who has a really quiet, internal micrphone, despite it being boosted to maximum on the Windows-side. Will look into the other approach (mixing) as time permits.

I don't know how to understand the impact of this. However, "reverb" is a hot button for me. Reverb is very bad for barbershop.

This was just a hint about a possible place to add the proof of concept to. As said, I currently do not propose this change to be merged. Also, it's not tied to reverb at all, it just happens that this is a good place to add audio processing for all platforms.

[hoffie]

Will look into the other approach (mixing) as time permits.

Sadly, this will be harder to implement in a backwards-compatible way than I hoped. The CHANNEL_GAIN message is strictly specified to take a two bytes and those two bytes are fully used for the existing fader range of 0-100%. I don't think we can extend the existing protocol message in a backwards-compatible way.

I thought about adding a new server option which would extend the fader range by a given factor (e.g. --servergainmultiplier 2 would lead to a client's faders 100% to mean 200% in the mix), but I'm not convinced that this is a good idea. First, it's not like people (or at least: I) would have to set it to "2". I would have to set it to 6-8 in order to compensate for the really quiet microphone of one of our choir members. Second, this would be really annoying for stored fader levels when hopping between multiple servers with different gain multipliers.

So, in summary: I really want such a feature, but I am still unsure what option to take. I see the following options:

1. Provide a one-time client-side configuration option (i.e. in the settings window) to set an input gain (that would be the more usable implementation of my proof of concept mentioned above). This should be rather simple to implement. An optional future enhancement could be some kind of "calibrate my input signal" which would instruct the user to sing/play some standard sound, warn them if audio is clipping and calculate a scale factor automatically if gain is required.
2. Provide a server-side gain scale factor which essentially changes fader levels from the default 0-100% to 0-$SCALEFACTOR*100. This should be rather simple to implement, but would have the above mentioned downsides.
3. Extend the Jamulus protocol to enable modern clients which are connected to modern servers to allow fader levels beyond 100%. This would be the technically most ambitious approach by far as it requires client, server and protocol changes and would need to come with appropriate testing for backwards compatibility.

My tendency would be towards option 1 due the simplicity.

Any opinions, especially from a usability perspective?

[gene96817]

The mental model I use for the audio input (the microphone) is:

• If the driver has a volume control, then this control is equivalent to a "digital preamp gain control". This volume control affects the setting in the analog portion of the chipset. After this control is the A/D.
• Once out of the A/D it is all bits into the Jamulus client and forwarded to the Jamulus server. Everything is digital until the Jamulus client send the digital stream to the output device.
• One problem is if the user sets the drive volume control too hot, then their sound will be distorted and no amount of fiddling with the Jamulus controls can undo the distortion.
• If the user's mic gain is too low, then (just like the analog version), we can turn up the Jamulus gain but we will also be amplifying the noise (the hiss).

Unfortunately, unless there is an API in the AISO driver, getting at the analog chip controls is all chipvendor proprietary.

[hoffie]

I have meanwhile opened #1222, which adds an Input Gain setting in the Client's setting dialog. Multiple people from my choir have been using this version successfully to boost their input signal to acceptable levels. I think this is the simplest solution which gets the job done.

[hoffie]

After further discussion on the PR, it has been merged. The next Jamulus version will have a way to apply an Input Boost via the settings dialog.

[ghost]

Internal computer microphones will pick up extraneous noises and are basically junk. Jamulus cannot make up for hardware shortcomings. Get a better microphone ... I did!
Moreover, amplifying a digital signal requires that a stream of data has to be tapped into and every sample must have a multiply operation done ... This decreases the resolution of the data which increases quantization noise (as if that matters, but that's what you get for your trouble). Now everybody who doesn't have a crappy microphone has to put up with more bloat and less preformance for the sake of someone who insists on using an internal microphone which can only be improved marginally by adding gain and noise gates (throwing good money after bad).
Code added to Jamulus for bad microphones should be, at best, #ifdef'd so that it is optional.

[S-luap]

From my perspective, the more significant (and more prevalent) problem is singers whose microphone is set too loud, who struggle to know how to turn it down (often mistakenly thinking think that their fader in the personal mix does that). I’ve also come across a few users (mainly Mac), whose mic level keeps automatically resetting itself to 100% - possibly due other applications running in the background (Skype, Zoom etc.) that are trying to auto-level - but I’ve not managed to conclusively prove that yet. We haven’t had anyone whose level was too low, where we haven’t been able to sort them out - usually turns out to require a one-time instruction and level setting, or that they had their onboard mic connected to Jamulus by mistake and were fruitlessly turning up the level on the mic they thought they were using. Personally I haven’t experienced anyone trying to use a mic where it was impossible to get a reasonable input level. (Everyone has either a headset with mic, or a separate mic connected through USB or sound box). So for me, the more useful feature would be to have control within Jamulus over how much of the available input sound (100% down to 0%) is being allowed through / sent to the server. In the choruses I’m in that use Jamulus, I haven’t seen a need to be able to amplify the input sound - and if that will cause distortion or deterioration in the sound quality then it could create additional problems.

…

Sent from my iPad

On 10 Mar 2021, at 22:47, DavidSavinkoff ***@***.***> wrote:  Internal computer microphones will pick up extraneous noises and are basically junk. Jamulus cannot make up for hardware shortcomings. Get a better microphone ... I did! Moreover, amplifying a digital signal requires that a stream of data has to be tapped into and every sample must have a multiply operation done ... This decreases the resolution of the data which increases quantization noise (as if that matters, but that's what you get for your trouble). Now everybody who doesn't have a crappy microphone has to put up with more bloat and less preformance for the sake of someone who insists on using an internal microphone which can only be improved marginally by adding gain and noise gates (throwing good money after bad). Code added to Jamulus for bad microphones should be, at best, #ifdef'd so that it is optional. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[gene96817]

So far, for Mac users, I have found the System Preferences/Sound/Input controls adequate for setting the microphone level before Jamulus. All my troubles are with WIndow users and ASIO settings that do not allow adjustment of a microphone level.

[S-luap]

As mentioned previously, in my experience, singers having their microphone sensitivity set too high is a much more common and problematic issue than people having mics that can’t send in sufficient volume. Is it “boost” only, or will it be possible to attenuate the signal too? If it can address both circumstances - too quiet and too loud - that will be a useful and welcome enhancement.

…

Sent from my iPad

On 31 Mar 2021, at 21:36, Christian Hoffmann ***@***.***> wrote:  After further discussion on the PR, it has been merged. The next Jamulus version will have a way to apply an Input Boost via the settings dialog. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[hoffie]

Is it “boost” only, or will it be possible to attenuate the signal too?

@ann0see asked the same question on the PR:
#1222 (comment)

Summary: It only allows boosting, not lowering the volume, because I don't think it provides value as explained there. I'm happy to be convinced otherwise. :)

What's the problem with people having their microphone sensitivity set too high in your case? Is it about clipping?

[dcorson-ticino-com]

Note that if Jamulus receives a signal that is clipping, Jamulus can not do anything to alleviate that.

[S-luap]

It’s not been noticeably about clipping - it’s more about helping singers in large ensembles to get a reasonably consistent level of input, which makes it much easier for everyone to get a good balanced sound. Yes, everyone can tweak their own personal mix to deal with those folks who are much louder than everyone else, but it’s better if the problems are fixed at source by having each singer adjust their own input to be in a reasonable range, rather than everyone else having to compensate. Of course that can (and should) be done in Windows or Mac sound settings, but not every Windows user is adept at navigating through the labyrinth of Window Device Settings dialogues, and most inexperienced users intuitively think there should be the ability to adjust / turn down your Jamulus input from within Jamulus. We have also encountered several Mac users whose mic level keeps automatically resetting to 100% every now and then. Obviously this is a Mac issue, and not really for Jamulus to sort out, but we haven’t managed to find out what’s causing it and how to stop it happening - so if they could leave their mic level at 100% and attenuate the signal that Jamulus is sending to the server that would avoid everyone else having to keep adjusting faders in their personal mix whenever the Mac users’ mic level suddenly randomly resets back to 100%. Finally, we have been making use of the server side recording feature to capture multi-track recordings (which is a brilliant facility), and this gives much better results if everyone’s input levels are consistent, and again if that is achieved by each user being able to easily and reliably adjust their input level within the Jamulus client it would make life easier. Having said all that, I accept I haven’t been actively participating in the discussion on Github, so I’m happy that you’ve answered my question, and confirmed that the enhancement will only allow an input boost. For the members of the choruses I sing with that will be of limited value (fortunately we don’t have anyone using a mic which is unable to provide an acceptable input level), but presumably other users that have participated in the discussion do have situations where it will be useful.

…

Sent from my iPad

On 31 Mar 2021, at 22:16, Christian Hoffmann ***@***.***> wrote:  Is it “boost” only, or will it be possible to attenuate the signal too? @ann0see asked the same question on the PR: #1222 (comment) Summary: It only allows boosting, not lowering the volume, because I don't think it provides value as explained there. I'm happy to convinced otherwise. :) What's the problem with people having their microphone sensitivity set too high in your case? Is it about clipping? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[hoffie]

Thanks for explaining your use cases. I understand that it would provide value for you. I'd be open to extend the feature to allow for reducing gain. However, I still see a huge problem in the fact that it would hide clipping. I can't come up with a simple idea to work around that. Do you have one?

Other ideas which may (partially) help:

• Short-term: The next Jamulus version will include One-click Automatic Fader Adjustments, which may be a huge help for everyone in the group to get a good mix.
• Long-term: There have been discussions about first-use assistants which could possibly include a input level callibration which guides the user to adjust the level (or uses Jamulus-internal features to adjust if that fails). This could also include a clipping check to only allow signal reduction if clipping is not already an issue.

[S-luap]

Sorry, I don’t have an answer to the problem of hiding clipping. But if someone is sending in a loud, clipped signal, and other users turn them down with the fader in their personal mix, aren’t they also just reducing the volume of the clipped signal that they hear? Is the the end result for the listener any different to what would happen if the original (clipped) input signal was being attenuated before being sent to the server? Thanks for the insight on the upcoming enhancement and potential long-term ideas. The automatic fader adjustment is interesting, and will definitely help in my use cases. But could that also hide clipping, or will it include logic to detect & highlight clipped input? (Just out of interest, is the feature planned to be a continuous, dynamic levelling, or just a one-off on-request adjustment? (The additional processing of continuous adjustment could impact on latency / delay times?)).

…

Sent from my iPad

On 31 Mar 2021, at 23:53, Christian Hoffmann ***@***.***> wrote:  Thanks for explaining your use cases. I understand that it would provide value for you. I'd be open to extend the feature to allow for reducing gain. However, I still see a huge problem in the fact that it would hide clipping. I can't come up with a simple idea to work around that. Do you have one? Other ideas which may (partially) help: Short-term: The next Jamulus version will include One-click Automatic Fader Adjustments, which may be a huge help for everyone in the group to get a good mix. Long-term: There have been discussions about first-use assistants which could possibly include a input level callibration which guides the user to adjust the level (or uses Jamulus-internal features to adjust if that fails). This could also include a clipping check to only allow signal reduction if clipping is not already an issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[hoffie]

But if someone is sending in a loud, clipped signal, and other users turn them down with the fader in their personal mix, aren’t they also just reducing the volume of the clipped signal that they hear? Is the the end result for the listener any different to what would happen if the original (clipped) input signal was being attenuated before being sent to the server?

No, the audio end result is the same, but Jamulus is able to display a clipping indicator (red border), i.e. it's obvious who contributed the clipping. When reducing the signal level on the input side, this information gets lost as the server can't know it.

But could that also hide clipping, or will it include logic to detect & highlight clipped input?

I don't think it would hide clipping (in the sense of breaking the red clipping indicator) as it only uses the existing gain adjustment faders.

(Just out of interest, is the feature planned to be a continuous, dynamic levelling, or just a one-off on-request adjustment? (The additional processing of continuous adjustment could impact on latency / delay times?)).

The related issue was #966, the related PR was #1071.
In summary: It is a continuous monitoring of existing level information with a user interface to apply fader changes by a shortcut or menu click.

[S-luap]

Thanks for answering my questions, and for the links and clarifications.

[hoffie]

BTW, if you want to try it out right now, there is a pre-release available at https://github.com/jamulussoftware/jamulus/releases/tag/r3_7_0devNightly1 :)

[S-luap]

Thanks, I’ll give that a try later.