First release candidate of Jamulus 3.8.0 has been released

[softins]

We have just released version 3.8.0rc1 of Jamulus, and would be happy for you to download, compile and test out this version. If all is well, this will become the 3.8.0 release.

Please note that the package for Mac now requires macOS Sierra (10.12) or later, and is no longer compatible with Yosemite (10.10) or El Capitan (10.11).

You can view the Release Notes and download versions for Windows, Mac, Linux (Debian/Ubuntu) and Android (still experimental) at https://github.com/jamulussoftware/jamulus/releases/tag/r3_8_0rc1. You can also download the source code as a zip or tarball for compiling, or you can check out the code using git.

If you find any issues with it, please raise an Issue with as many details as possible.

[iamthechrisb]

Hi Team -- I'm ChrisB on Jamulus, and host 🌊CBVB🌊 in Virginia, USA. We have regular users from most of the eastern US and southeast CAN. I have to tell you that this is the best sounding Jamulus code so far, a very impressive improvement. Well Done!

I've had it running since release, and everyone has been really pleasantly surprised. We're also running delaypan, which has made the experience incredible. The increase in cpu util with delaypan that is pretty significant, particularly when hosting larger groups.

A couple of questions

1. I run most of my services on arm -- are there missing optimizations in the rc for arm?
2. Are the overall improvements related to a change in how opus was pulled into the project?
3. Will we see higher fidelity opus bitrates soon?

Thank You again from me and the many people who jam on 🌊CBVB🌊 -- well done!
ChrisB

[ann0see]

The increase in cpu util with delaypan that is pretty significant, particularly when hosting larger groups.

Yep. Just had a rehearsal with < 20 users on a quad core server and one core maxed out while all the others were pretty low with delay panning (I'm still running a beta on this server and didn't test the multi threading improvements yet). Unfortunately I had to disable it in order to have usable sound quality.

[iamthechrisb]

Hi Chris,
I am also running an ARM server (Odroid-N2) and have measured 9% more load with delay-pan on.
Are you seeing more ?
In any case it is so good I would rather reduce my max users than turn it off.
As I heard there were some opus optimisations that were turned off by mistake a couple of versions ago that have been reinstated.
As to higher fidelity ????? I don't know.

Sounds about right, Quickly looking as I was playing too.. I was estimating I saw 10% with ~15 users. This particular room was running on a Graviton2-based processor.

[iamthechrisb]

There may be an indirect increase in resource usage when testing with/without delaypan: Users (especially singers?) will often use Mono channels by default, but will have switched to Mono/Stereo-out when trying delaypan. Stereo mixing obviously takes more resources.

I run most of my services on arm -- are there missing optimizations in the rc for arm?

I don't think so. Jamulus core is plain C++ without any platform-specific optimizations. The compiler may and will optimize though. There may be ways to try to optimize more aggressively by playing with compiler flags (e.g. -O3 instead of the default of -O2 (I think)).

If Jamulus 3.8.0 uses more resources than 3.7.0 even without delaypan, then it would be good to investigate where this comes from.

Are the overall improvements related to a change in how opus was pulled into the project?

The opus version is unchanged. However, @npostavs discovered (and fixed) that the opus code which we are vendoring wasn't built in the optimal way. Opus does contain platform-specific optimizations (ASM) and 3.8.0 includes the change to use this optimized code instead of the default non-optimized code.

Some high-level benchmarks did not show any significant improvements, sadly. :(

I'm still not sure what parts in the audio processing take the most CPU time, e.g. whether it is mixing itself or opus encoding/decoding.

Will we see higher fidelity opus bitrates soon?

I once planned to play with VBR for that, but tbh other things have more priority right now. I think opus has very good sound even with low bitrates. The main problem (or rather: feature ;)) is that Jamulus uses a custom opus encoder to achieve the lowest possible latency. opus disables several of its optimizations in this mode. This leads to a rather sub-optimal sound compared to the used bandwidth. So one option is allowing more bandwidth usage or accepting slightly higher latency in the encoder/decoder to achieve a better quality/bandwidth ratio.

Long story short: Unless someone takes this up, no near-future improvements are known to be planned right now as there are other priorities.

Got it -- the custom encoder was what I was thinking of. I had seen something go by in messages about the custom encoder, but didn't know if that was changed -- if this was the change that we hear now. I think it sounds really great now, and that's what matters the most. In my situation, I'm paying for bandwidth -- so for general use, I probably wouldn't run a higher rate. However, I do think it is a good idea to support the same opus rates as as some of the other options out there, but I'm saying that without being knowledgeable about the tradeoffs -- or the complexity of that change. Thanks for the reply!

[dcorson-ticino-com]

one core maxed out while all the others were pretty low with delay panning (I'm still running a beta on this server and didn't test the multi threading improvements yet).

Well turn that multi threading on real quick. At least on an ARM server it works really well, also together with delay-pan. As I calculate it should max out at something over 35 users, I set 25 to have lots of headroom and 25 works well.
I see about 9% more processor load with delay-pan.
That is on a cheap (~80$) one-board compi running an ARM processor. Something running an Intel processor should be much much faster.

[ann0see]

Multithreading was already on. As far as I know, one core is for compressing and sending while all others are used for mixing. Maybe in future we should investigate that further (but not yet).

I‘ll soon try the latest code.

[DetlefHennings]

It seems, that in server mode the 'delay pan' option is not stored in the 'ini'. I observed this on Windows 7 and on an Ubuntu based system.

[hoffie]

Thanks. I've opened #1743 to track this. Seems like this was an oversight -- I'm not seeing any code which even attempts to make this work yet. :)