Inconsistency between Input meter and Audio mixer meter

[fleutot]

During soundcheck, we experienced a player clipping on their input, but not in the server audio mixer. The musician (midi drums, is that right @enorson?) was asked to increase their input gain, although it sounded distorted on their hand.

Inversely, I (a trumpeter) am often asked to decrease my gain, although my input level is barely in the yellow.

This discrepancy confuses people. I understand that because of available computational power, the implementations of these levels have to differ (right?), but if there's something that could be done, it would be welcome.

[pljones]

People should not be using the level meters for anything significant. Ideally, even the input meter should only be used as a reminder. You should be setting up prior to connecting to Jamulus using a more accurate guide, if you need it - i.e. one that actually tells you your level in dB.

Then you need to take other things into account - an electric guitar with overdrive and distortion at -12dB can "sound" louder than a drum kit at -6dB. (I think because of the frequency coverage and duration of sounds.)

Jamulus audio uses 16 bit fixed point audio. It uses a lossy codec. You're running over a lossy network protocol. All these factors need to be taken into account.

If you're used to mixing in 32 bit floating point, you're probably aware you've got some leeway above 0dB you can play with. Not in Jamulus -- you clip, that distorts.

If you're used to using lossless audio when editing, you'll expect that what you save sounds the same when you load it back in. Not in Jamulus -- the equivalent is the codec compression / decompression cycle and that's lossy, so you're going to sound different. You need to hear yourself through Jamulus - the mix from the server only - to know what others are hearing.

And the lossy network protocol is another issue that means hearing yourself from the server is important. That way you'll get to hear the problems that lost packets cause - loud spikes from glitches are the most common.

So, if people say they hear you as too loud or too quiet, that's not to do with the meters, that's to do with your level and how they hear you.

For acoustic instruments, it's very hard - especially louder ones like drums and (un-muted) brass. I'd suggest connecting to a server that records, playing a set, then getting the recordings and compare it to what you were hearing whilst playing. That should give you a clearer idea.

Of course, for electric DI'd instruments and electronic, it's a lot easier, as you can set up only to hear through Jamulus very easily.

[corrados]

I agree with pljones. This issue is sort of already covered by this one: https://github.com/corrados/jamulus/issues/86

[fleutot]

Thanks for the answer. I'll make sure our soundcheck master (and others) reads this.

[fleutot]

I saw in that other issue that you first considered having a single LED instead. I think that would lead to less confusion, people wouldn't assume that the bar is what it isn't, if it wasn't there at all. How about a LED indicator that varies in intensity depending on (rough) input level? Maybe with a smooth decay on client side?

EDIT: I assume people would get mad at "losing" the audio mixer meters, but on the other side if they aren't what they think they are...

[fleutot]

@pljones wrote:

For acoustic instruments, it's very hard - especially louder ones like drums and (un-muted) brass. I'd suggest connecting to a server that records, playing a set, then getting the recordings and compare it to what you were hearing whilst playing. That should give you a clearer idea.

This touches on something related that I miss: easily setting levels with audio feedback from server. I can set my hardware alright, but I cannot check how it's going to sound on and through the server without the whole server room hearing it as well. I guess some kind of side channel with the effect of "mute myself to others" would solve this. Would this be worthy of a feature request? A further feature would be the possibility to add a user defined delay (up to a few seconds) to the playback, useful for louder acoustic instruments (the "record and listen" procedure you mention, made easy).

[pljones]

I guess some kind of side channel with the effect of "mute myself to others" would solve this.

That's what "Mute Myself" (prior to the mixer, on the left near the "Chat" and "Settings" check boxes) does, I think... (not sure...)

Also, finding an empty server isn't hard -- if people turn up and you're setting up, use chat or your mic to say so and you can just mute them, too.

[fleutot]

When I use "Mute Myself", I get no (network) delay, I just tested with a server 100 ms away. I think its direct sound. If I understand correctly, the point was to involve the server to hear how it sounds. If Mute Myself uses direct sound, that point is moot.

Doing this on another server is not the same either? I suppose that different servers would get different results?

There isn't much to do but adjusting my input gain, anyway. If I can make sure in another tool that I'm not clipping (Audacity, I guess), maybe that's enough.

My original point still stands: the discrepancy is confusing. This is me playing a long sustained tone on the trumpet (VU meters quite constant):

[corrados]

The difference is not supposed to be so large if your input level is constant. When I have time I'll try to reproduce this issue and see if I find a bug causing this.

[WolfganP]

@fleutot another test you can run is connect to a server on the same machine the client is running, so you have a complete loop thru a server without any network delays in between.

[pljones]

@fleutot It would help if you could state the dB level you're playing (a little) - do you have a way of routing your signal both to a dB meter in a DAW and to Jamulus (same signal, obviously :) )?

I was aiming for anything over -9dB to fill the remote meter (3 on a scale of 0 to 3), meaning "loud enough", anything over -18dB to get the halfway point (2 on the scale), anything above about -36dB to register and below that not to show at all. I may have got my translations from sample value to dB wrong...

The initial aim was to let people see when they're not playing loud enough. The other thing is, if everyone's constantly filling the meter, the mix is likely to clip, as it's fixed point.

(I don't actually know what triggers the new clip indicator - I hope that's when the sample actually hits max value, not when the meter hits 3..!)

[corrados]

I don't actually know what triggers the new clip indicator

I was re-working the channel level meter recently. I noticed that the protocol supports 4 bits but actually only about 3 bits are actually used. It goes from 0-8 and for the -max short (i.e. -32768) it transmits a 9. This triggers the clip indicator. I.e. only the full scale level triggers the clip indicator which is what I want to have.

[fleutot]

It would help if you could state the dB level you're playing (a little) - do you have a way of routing your signal both to a dB meter in a DAW and to Jamulus (same signal, obviously :) )?

Good suggestion! Interestingly, Audacity seems to agree more with the audio mixer than the input meter.

[fleutot]

Out of curiosity, what hinders computing the level on the sending client? It's able to add Reverb, so computing the level of a buffer before sending it should be doable. Attaching the buffer level should not be a big overhead (especially if you're only sending 8 levels, but why not send 256, it's only a single byte). The server would only need to send an array of n_users*bytes (or times half a byte if you want to keep the low resolution) a few times per second, forward the data without computing anything.

I suppose there's something in the way, but I don't see what. That could ease making the input and audio mixer consistent.

[fleutot]

@pljones wrote:

-9dB to fill the remote meter (3 on a scale of 0 to 3), meaning "loud enough"

I think that's part of the problem: people see red on someone else's meter, and they'd tell you to get a grip and lower your input. Sometimes angrily :) Maybe that's right, I mean if you're in the red you're eating up the headroom even if you don't clip, I don't know.

[corrados]

I was aiming for anything over -9dB to fill the remote meter (3 on a scale of 0 to 3), meaning "loud enough", anything over -18dB to get the halfway point (2 on the scale), anything above about -36dB to register and below that not to show at all.

I don't think that is the case anymore. As I wrote above, the current signal level is mapped to 8 steps, not to 4. Recently I have changed that the server also uses the same class as the local input level meter: https://github.com/corrados/jamulus/blob/master/src/server.cpp#L1638 https://github.com/corrados/jamulus/blob/master/src/channel.cpp#L665

[pljones]

@fleutot As @corrados says, I was speaking about my initial implementation -- I hadn't really noticed it had changed significantly. I'll need to remember this! :)

[corrados]

I cannot reproduce this issue. I did the following test. I put the following code at the beginning of the ProcessAudioDataIntern function in client.cpp:

static int test = 0;
test++;
const int iTest = ( test / 400 ) % 20;
for ( i = 0, j = 0; i < iMonoBlockSizeSam; i++, j += 2 )
{
    vecsStereoSndCrd[j + 1] = (double) _MAXSHORT / iTest * sin ( 6.2 * i * 440 / 48e3 );
    vecsStereoSndCrd[j]     = 0;
}

That basically generates a sinusoidal tone on one of the stereo input channels and changes the level of that signal with time. Here is a video of a test I did with that code: As you can see, the local level meter and the remote level meter are in sync.

[fleutot]

@corrados I'll see if I can send a sound sample. From what I can see, the signal I get from my soundcard is not symmetrical at all, for example.

[corrados]

the signal I get from my soundcard is not symmetrical at all

What do you mean by "symmetrical"?

[corrados]

I'll see if I can send a sound sample.

Any updates on this?

[fleutot]

Sorry, here comes: https://www.dropbox.com/s/wmyt8vjj3cbmqq1/jamulus_meter_level_001.wav?dl=0 This shows the behavior at my place, input is well below clipping while audio mixer clips.

This is what I meant by "not symmetrical", the amplitude of the dip is much larger than that of the peak:

(verified on master c9e9dd59)

[corrados]

Thank you for the file. I have downloaded it and play it with foobar using the jack router under Windows. Your wave file is therefore directly feed into Jamulus. Here is what I get: What puzzels me is that I still cannot reproduce the issue. Even with the origianl file you provided. As you can see if you look at the local/server level meters that they seem to match pretty good...

[fleutot]

Interesting, I did the same thing and did not get that result. Do you run on a local server? I used a random public empty one in Sweden.

[corrados]

I have used the Central Server in the Default server list. Please make sure that you make your tests always with the most recent server version. You can check the version using this page: http://jamulus.softins.co.uk. As you can see, the Central Server uses 3.5.9git. What version has the server you have used for your test?

[fleutot]

Oh, what if we could also see what commit the server runs? xD just teasing.

Currently with the Central Server in Frankfurt:

[corrados]

Are you using exactly the same wave file or are you playing your instrument in your video? You are using Linux and I am using Windows. But I do not think that this would make any difference...

[fleutot]

Sorry. Here with the same file as input.

[fleutot]

It may not be a platform issue, but maybe compiler version? If there is any kind of UB (not saying there is), that could explain such differences.

[corrados]

I have just done the same test on my Ubuntu laptop and can still not reproduce the issue. I am running out of ideas what could be the difference between your computer and mine.

[fleutot]

Could QT versions play a role here? Maybe the progress bars have different behaviors?

[corrados]

I don't think so since you also get a clipping which I do not see. Are you using the internal OPUS library or do you use a special CONFIG with qmake when you compile Jamulus?

[corrados]

Let's do some theoretical discussion of what can cause the issue you observe:

1.) In the client, only every third sample is evaluated. In the server much less samples. So the probability of detecting a high peak should be higher on the client. But just the other way around is what you see: the server meter shows a higher level.

2.) The input signal in the client is the uncoded signal wheras the signal in the server went through on OPUS encoding/decoding. If you have highly unsymmetric signals, I don't know how the time series of the signal will change after the OPUS coding. The only explanation of the higher peak would be that the OPUS codec amplyfies peaks in the time domain.

Does this sounds reasonable?

[fleutot]

Sure, what I don't get is why you don't get the same effect with the same input signal. I haven't actively chosen another encoding than what comes out of the box on git clone.

[corrados]

@pljones Could you please do exactly the same test as we both did? It would be good to have a third example. Would be interesting if you see what I see or what fleutot sees.

[pljones]

I've grabbed https://www.dropbox.com/s/wmyt8vjj3cbmqq1/jamulus_meter_level_001.wav?dl=0 Loaded into Reaper (AppMovie recorded in MuLab) Played out through Jamulus to local server and back (although you'll see my local's muted)

http://peter.drealm.info/img/AppMovie-20200818-230003.mp4

Reaper says the max is -2.4dB. The remote meter appears to peak occasionally The local meter doesn't peak

The local meter tracks Reaper's display very closely. I'm not sure what the current behaviour of the remote meter is meant to be but it'll be affected by the OPUS encode/decode.

Client is freshly installed 3.5.10 running on Windows 10. Server is cf63bbef (r3_5_10 plus feature/save-recorder-settings) built "nosound headless", running on Ubuntu.

[corrados]

Thank you. As far as I can tell, your video looks more similar to mine than to fleutot's video. @fleutot Do you agree? I hope that this issue is not similar to what we have here: https://github.com/corrados/jamulus/issues/369. There seems to be an issue which is only seen on one type of Linux.

[fleutot]

I agree. I wonder how it would look like if I play the file as my input, while someone else watches the audio mixer on another client.

[pljones]

Just to try it over on a pure Linux set up: http://peter.drealm.info/img/AppMovie-20200819-131738.mp4

• Start up Jamulus server and client (which starts JACK)
• Connect Jamulus client to server
• Start up Audacity, use JACK, and load up the sample data (I also inverted it to see the peak more clearly)
• Connect Audacity's output to Jamulus client
• (Jamulus I/O to JACK, Audacity in from JACK system, JACK with "nosound" driver)
• Hit play (Audacity goes "loud!" nearly every time around, remote doesn't at all here -- presumably it's "count" isn't catching the peak this time)

(Background magic in MuLab to record the video and in Handbrake to edit it.)

Here it looks like the two meters are much more closely aligned - although the remote seems to be getting a little "bump" in level that the local one misses - I guess there's something just on an edge there and the OPUS codec pushes it over.

[pljones]

Given that the guys on Jamulus Worldjam are using the mixer level meter for their back stage sound checks to their satisfaction, can this now be closed?

[fleutot]

Sure. I guess I'll never know.