Why such high bitrate? Improve and enable more use cases?

[38github]

I have always wondered why using Enable Small Network Buffers, stereo and highest audio quality result in over 900 kbps and still have some audio quality issues. If I encode music to Opus using the smallest 1.5ms frame size and a bitrate of between 192-224 kbps I hear no difference.

1. Can the bitrate size and audio quality of Jamulus opus codec implementation be optimized or user adjustable?

If so, then maybe we, who have high bandwidth internet, can archieve better audio quality while also enabling for people to setup "low bitrate" servers with even lower bitrates possible today for those who are very bandwidth limited.

Keep up the good work, everyone!

[dcorson-ticino-com]

Hi 38,
Note that enabling the small buffers does not change the Opus encoding, it is no wonder you hear no difference.
The small buffers are there to lower the latency.
Low latency is seen by the Jamulus developers as being more important to being able to play together well than very good audio quality.
Note that there are thoughts in the pipeline to also improve the audio quality in the future.

[38github]

Hi there,
I haven't noticed a sound difference between not using small buffers and using small buffers but with Enable Small Network Buffers doesn't it lower the frame size inside opus and therefore need more bitrate to sound good?

What exactly is done or not done that requires this huge amount of bitrate in Jamulus? Complexity, frame size, disabling of features in Opus, etc?

[dcorson-ticino-com]

I do not know all the details, but imagine that as we are sending more very small packets to reduce the latency the packet overhead is becoming a significant portion of the data transfer volume.
In my case I am seeing an increase in data flow of about 24% which should be seen in the light of a reduction of latency of about 9ms. Nothing to be coughed at.
You may be seeing other figures, but I think that bit of bandwidth is very worth that reduction in latency if you have a good connection.

[38github]

But the packets can't be or are not smaller than the smallest opus frame size (1.5ms)?

[hoffie]

I have always wondered why using Enable Small Network Buffers, stereo and highest audio quality result in over 900 kbps and still have some audio quality issues.

I noticed that, too, and thought that it might be due to the very small frame size which forces opus to either disable certain optimizations or makes existing optimizations way less effective.

If I encode music to Opus using the smallest 1.5ms frame size and a bitrate of between 192-224 kbps I hear no difference.

That's interesting -- I would have expected that to sound similar. This sounds like something that would be interesting to investigate.
Some ideas:

• Jamulus uses CBR which might affect things while plain opus will choose VBR by default (IIRC)
• It might be interesting to measure the actual network traffic. The displayed bandwidth is a manual calculation (although the logic looks sane to me).

with Enable Small Network Buffers doesn't it lower the frame size inside opus and therefore need more bitrate to sound good?

Yes, that's what I assume as well.

What exactly is done or not done that requires this huge amount of bitrate in Jamulus? Complexity, frame size, disabling of features in Opus, etc?

I don't have a direct answer to your question, but you can see the exact opus configuration here:

jamulus/src/server.cpp

Line 254 in a4c8620

// create OPUS encoder/decoder for each channel (must be done before

Can the bitrate size and audio quality of Jamulus opus codec implementation be optimized or user adjustable?

It currently isn't. Jamulus uses opus directly, with no ogg or webm container which would usually contain the information about codec parameters (IIRC). That means that the choice of opus parameters has to be part of the Jamulus protocol. This part only supports the existing modes right now. Additional modes could be added, but would introduce more complexity. In addition, all audio and and buffer handling currently works with static frame sizes (CBR). Opus optimizations would likely also contain VBR, so this would require some re-working (which I think is possible, but not as straight forward as the existing modes).

We should also note that other modes may not only affect the network bandwidth, but also CPU usage (mainly in the server). It may also mean that CPU usage is no longer that predictable. We should be careful to handle the case that a load test with 50 empty client works on a server, but that the server would start struggling once the silence would be replaced with actual music.

Personally, I'd be open to something like this in general, but to judge whether it would be acceptable we would have to know how much complexity it would introduce.

[38github]

Thank you for the thorough answer.

I notice the issues with audio quality I have a distorted guitar with a short stereo room reverb and guitar is panned slightly to a side. I would have to try it out again to be able to describe what issue I would hear though. It is not the end of the world since the audio is absolutely acceptable considering that it allows me to jam with other people.

I am looking forward to see if it suddenly shows up a PR about bitrate/quality improvements. Setting up a server with a low bitrate but still ok where bitrate constrained people can jam would be really interesting since some people still seem to have i.e. DSL 256kbps up/down.

[dcorson-ticino-com]

A little bandwidth test, just for fun, using cbm on my Ubuntu server and Taskmgr on Win10 both give the same values:

64 samples, small buffers enabled up (from client) 700kbs down 708kbs
64 samples, small buffers disabled up 626kbs down 634kbs

The calculated values reported by Jamulus are not very real, will have to look into this.

[38github]

I think it shows up as lower in windows compared to Linux if I am not wrong. Linux says something like 900 and Windows 700. I am not sure about it right now and would have to try it out again.

[dcorson-ticino-com]

I am on a Win10 client and see 906kbps.
Obviously not correct.

[38github]

Can it be that I have (I think) seen around 700 kbps if the server isn't setup to use -fastupdate?

[dcorson-ticino-com]

If the server isn't doing -F it tells the client it can't in the handshake and it is disabled in the client even if the check is set there.

[38github]

And that leads to lower bitrate I presume (which might have fooled me)?

[npostavs]

I have always wondered why using Enable Small Network Buffers, stereo and highest audio quality result in over 900 kbps and still have some audio quality issues.

The audio quality issues are probably not due to encoding quality, but rather due to dropped/late packets. Try setting the Jitter Buffer to manual and increasing both settings to maximum. The downside is that you'll have more delay though.

[38github]

It is not droupouts but lossy artifacts I hear.

[hoffie]

I do hear sporadic audio artifacts even when running with maximum buffer sizes on localhost and re-playing a local recording via jack (e.g. ruling out any issues with audio capture). I've never done a manual-low-latency-opus-encoding vs. Jamulus-encoding comparison though.

[passing]

The number that is shown to the user as "Audio Stream Rate" is calculated here:
https://github.com/jamulussoftware/jamulus/blob/master/src/channel.cpp#L717

It adds 28 + 26 + 23, so 77 bytes per frame, while actual audio data is something between 12 (mono/low) and 165 (stereo/high/double framesize) bytes per frame.

If you do the calculation without the header, the actual audio-only data rate should be for mono:

• 72kbps (low)
• 132kbps (normal)
• 216kbps (high)

which looks quite reasonable in general, while the high setting seems to be a bit over the top. But this is just my outside view