Hardware requirements

[lorbeerbund]

Good evening,

I am a Jamulus beginner. As a test, I have set up two clients:
one on a slightly older Macbook Pro (via WLAN)
and one on my PC (Linux Mint via LAN):
~$ inxi -Fz

• System:
  Kernel: 5.8.0-49-generic x86_64 bits: 64 Desktop: Cinnamon 4.6.7
  Distro: Linux Mint 20 Ulyana
• Machine:
  Type: Laptop Mobo: N/A model: N/A serial:
  UEFI: American Megatrends v: 5.13 date: 03/18/2020
• CPU:
  Topology: Quad Core model: Intel Core i5-8265U bits: 64 type: MT MCP
  L2 cache: 6144 KiB
  Speed: 800 MHz min/max: 400/3900 MHz Core speeds (MHz)
• Graphics:
  Device-1: Intel UHD Graphics 620 driver: i915 v: kernel
• Audio:
  Device-1: Intel Cannon Point-LP High Definition Audio
  driver: snd_hda_intel
  Sound Server: ALSA v: k5.8.0-49-generic

Under Settings I selected "Mono" and "Audio Quality Low" in both clients, also "Jitter Buffer: auto" and "Enable Small Network Buffers". From both devices, I dialed into the same available Jamulus server (from different rooms on the same network). On both devices I connected a good headset via 3.5 mm connector. This possibility has proven itself with Teams/Zoom/Skype & Co.

With Jamulus, however, this hardware combination does not lead to acceptable results so far. The sound of the transmission in both directions is stuttering, crackling and offers too little bandwidth. The transmission of a long, interference-free tone, for example, is practically impossible. Each sound input produces a series of distracting accompanying noises. This is very unsatisfactory. The glitches are audible even when I am alone in the chat room and only hear myself.

Could it be due to the internal sound modules of these devices? Or is it due to the analog audio connections via 3.5 mm? Would the use of external audio interfaces via USB remedy this? - Having certainty about this questions seems expedient before I think about the expensive purchase of suitable hardware.

I would be very grateful for a knowledgeable assessment!
Many greetings
lorbeerbund

[vdellamea]

You may imagine that, if both systems give similar issues, the problem lies "above".

• in my experience, on MacBook the audio input is not bad and not causing any special issue.
• What kind of connection do you have? (cable, fiber, etc).
• What kind of ping and overall delay do you see?
• where is the server? Did you check with a different server among those available in the connection list?
• buffer size?
  Then:
• Avoid WLAN.
• Avoid "Enable Small Network Buffers" that might introduce noise (although it is on only with the smallest buffer). Use it only if everything is okay.
• Avoid running Jamulus in parallel with other programs known to use the network (cloud storage, messaging, etc). One way to try this on you pc is to boot JamulusOS from a USB drive.

[gilgongo]

Agree with all of @vdellamea 's recommendations. Might also be worth doing a "loop back" test to see what delay you get locally. Run a server on the same machine, then connect the client to localhost. That should give you an indication of the "base" delay you'll get from your hardware and drivers alone. If that's over about 25ms then you may need to consider a different audio interface, and if the sound is still breaking up then that might implicate something else which you might be able to isolate by booting Jamulus OS and see if it still happens in that environment.

[dcorson-ticino-com]

Hi Lorbeer,
From your description of the sound you are up against network problems, not problems in your hardware.
Do not use wifi, use a cabled connection. No matter how good your wifi it always adds noticable sound defects.
Be sure you are not using background programs that could be using network or processor resources without you knowing.
While you are using Jamulus the rest of the people using your home network should be reading books.
Netflix and other streaming services are network hogs that will reduce your joy with Jamulus greatly.
For best enjoyment you will want to get your network to the point where High Quality Audio and Stereo are working OK.
Try the tips from @vdellamea and @gilgongo and let us know how things are then going.

[lorbeerbund]

Try the tips from @vdellamea and @gilgongo and let us know how things are then going.

That's exactly what I'm going to do. Thanks for your quick answers!

[lorbeerbund]

Hello everyone

I am online with a 100 Mbit cable DSL.
I tried some of the offered servers, very close: Cologne (300 km) or in the Netherlands (500 km) and with low ping values.

• My PC is connected to the router via LAN:
  Ping 18 ms, Download 99.94 Mbits/s, Upload 40.83 Mbits/s.
  see https://www.speedtest.net/result/11282931229
  Main window of Jamulus:
  "Delay" and "Buffers" are constantly yellow and red.
  "Settings" of Jamulus:
  Mono, normal Quality
  "Enable Small Network Buffers" now deactivated.
  Jitter Buffer "auto" with values for "Local" and "Sever" around 11
  Audio Stream Rate: 366 kbps
  Ping Time: 15 ms
  Overall Delay: 55ms - 58 ms

• The MacBook Pro is connected to the router via WLAN:
  Ping 14 ms, Download 86.76 Mbits/s, Upload 41.88 Mbits/s.
  see https://www.speedtest.net/result/11282991006
  Main window of Jamulus:
  "Delay" and "Buffers" are reliably green, rarely yellow.
  "Settings" of Jamulus:
  Mono, normal Quality
  "Enable Small Network Buffers" now deactivated.
  Jitter Buffer "auto" with values for "Local" and "Sever" around 2
  Audio Stream Rate: 366 kbps
  Ping Time: 16 ms
  Overall Delay: 39 ms - 41 ms

I am surprised that the connection via WLAN has a lower ping and a faster upload than the LAN connection. The "Overall delay" is also significantly lower via WLAN than via LAN. Could it be that this fact corresponds with the experience that I get more Jamulus servers with the MacBook?

In fact, the glitches are significantly lower on the MacBook than on the PC, where I also get them when I dial into the chat room without a jam partner. Because I'm connected to the LAN with the PC, I naturally want to direct my sessions from there. That's why the glitches here are very unwelcome.

Many greetings
lorbeerbund

[vdellamea]

WLAN non necessarily has worst speed and ping (although it is strange that speed is faster than cable -this may point to some cable issue). The reason not to use it is jitter, which is higher than on Ethernet. A steady delay -up to some limit- is not an obstacle to playing. A variable delay is.

Said that, the 23-24ms of added delay on MacBook are somewhat usual with the 128 buffer. You may shave something switching to 64.

40ms on Linux is way too much, and are motivated by the auto buffers to 11. Since the network is the same, there is something wrong ongoing. @gilgongo suggestion of running a server on the same computer may help: if the difference delay decreases significantly, the issue is not on the computer. If not, since you are already a Linux user, try the JamulusOS route, that gives you a clean and "monotask" system.
One point of failure that someone mentioned in the past is the ethernet cable - if you have another one at hand, try to swap it.

[lorbeerbund]

Other results:

It is not due to the Ethernet cable.

1. It is brand new.
2. I replaced it with an older one, with no noticeable effect on the problem.
3. I tried a connection via WLAN, with no noticeable improvement.

I tested the Linux PC and the MacBook at https://www.dslreports.com/speedtest/ - with interesting results:

• PC via LAN:
  Download: 102.7 Mbits/s
  Upload: 44.8 Mbits/s
  Connection quality: B
  BufferBloat: C
  https://www.dslreports.com/speedtest/68082960

• MacBook via WLAN
  Download: 102.6 Mbits/s
  Upload: 40.2 Mbits/s
  Connection quality: A+
  BufferBloat: C
  https://www.dslreports.com/speedtest/68082950

Why the LAN connection is rated B while the WLAN connection is rated A+, remains a mystery to me. The problem of a BufferBloat is noticeable in both tests.

However, there are no SQM settings in my Fritz!Box router, and frankly, I don't have the stamina to fix the problem in the firmware of the Fritz!Box.

On my PC I tried to shorten the transmit-queue-length of the Ethernet connection, as it is suggested here, sadly also without significant success in the matter.

• ~$ ifconfig enp2s0
  enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
  inet 192.168.178.21 netmask 255.255.255.0 broadcast 192.168.178.255
  inet6 fe80::6505:b248:c601:eb04 prefixlen 64 scopeid 0x20
  inet6 2001:16b8:1793:b000:7a9c:ca5:f9ba:a3f7 prefixlen 64 scopeid 0x0
  inet6 2001:16b8:1793:b000:305:57e5:f98d:40dd prefixlen 64 scopeid 0x0
  ether 00:e0:4c:e9:23:25 txqueuelen 1000 (Ethernet)
  RX packets 12701933 bytes 10111549980 (10.1 GB)
  RX errors 0 dropped 719826 overruns 0 frame 0
  TX packets 8807683 bytes 1675161394 (1.6 GB)
  TX errors 1 dropped 0 overruns 0 carrier 0 collisions 0

• ~$ sudo ifconfig enp2s0 txqueuelen 500
  ~$ sudo ifconfig enp2s0 down
  ~$ sudo ifconfig enp2s0 up
  ~$ sudo ifconfig enp2s0 txqueuelen 0
  ~$ sudo ifconfig enp2s0 down
  ~$ sudo ifconfig enp2s0 up
  ~$ sudo ifconfig enp2s0 txqueuelen 100
  ~$ sudo ifconfig enp2s0 down
  ~$ sudo ifconfig enp2s0 up

Now I guess the only thing left to do is to try JamulusOS.
https://sourceforge.net/projects/jamulus-os/

Gute Nacht!

[gene96817]

Why the LAN connection is rated B while the WLAN connection is rated A+, remains a mystery to me.

It would be worthwhile to look at your computers network connection details for Ethernet. Specifically, check to see if the driver has selected 1Gbps or 100Mbps (through the auto-speed detect). If you have recent WLAN hardware, you could have 802.11ac and that could give you link speeds up to 400Mbps (not continuous). It is possible your ethernet connection is configured for 100Mbps.

[vdellamea]

Why the LAN connection is rated B while the WLAN connection is rated A+, remains a mystery to me.

This is most likely linked to the high amount of buffer you have on the PC vs on Mac: if in auto it goes up to 11, there is something that makes the connection latency very variable and this likely influences the rating, not the speed. It might be the connection itself, but due to all the tests you made, I think something is running on your computer that takes away resources (it might be also CPU, but you can check it easily with top; more likely network). Try JamulusOS to exclude this.

EDIT: I checked, and connection quality is related to packet loss, which might in turn be related to network congestion.

[gene96817]

If you are using wifi, remember the speed you measure is an "average". If there are other wifi nodes sharing the channel you are using, even if they do not use your access point, your wifi traffic will take turns with your neighbors to share the channel. This channel sharing could affect your ping and buffer measurements.

[lorbeerbund]

Without knowing exactly what I am doing, I've now followed another recommendation and added the following section to the /etc/sysctl.conf file on my computer:

# For enable FQ_CODEL, ECN, SACK, and DSACK (User edit 2021/4/19)
# See https://www.bufferbloat.net/projects/bloat/wiki/Linux_Tips/
net.core.default_qdisc=fq_codel
net.ipv4.tcp_ecn=1
net.ipv4.tcp_sack=1
net.ipv4.tcp_dsack=1

As a Linux user, you are used to some fiddling around. But even this did not have the hoped-for effect.

[jujudusud]

Is your Linux Mint configured for low latency ?

• kernel with audio low latency tweaks,
• PAM,
• Jackd2 realtime,
• priority to the sound.
• etc...

You should have installed the latest ALSA, Pulse audio, JACK2, etc...

[lorbeerbund]

Is your Linux Mint configured for low latency ?

* kernel with audio low latency tweaks,

• ~$ sudo apt-get install linux-lowlatency
  Paketlisten werden gelesen... Fertig
  Abhängigkeitsbaum wird aufgebaut.
  Statusinformationen werden eingelesen.... Fertig
  linux-lowlatency ist schon die neueste Version (5.4.0.72.75).
  0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
• ~$ uname -r
  5.8.0-50-generic

The latest lowlatency kernel (5.4.0.72.75) is installed, but the system runs on the latest stable (5.8.0-50-generic), because since 2012 special realtime features have been partially integrated into the standard kernel. ("However, since Linux 2.6, the real-time stack has been part of the Linux kernel, having a kernel patched with a real-time stack is no longer necessary." see https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel) Special audio kernels, such as those described here, are too insecure for my running desktop system.

* PAM,

/etc/security/limits.conf:

# For allow regular users to operate software at a high priority (real time) level.
# (User edit 2021/4/19)
@audio           -       rtprio 95             #99
@audio           -       memlock 512000        #unlimited
@audio           -       nice -19

The main user is a member of the "Audio" group.

* Jackd2 realtime,

• ~$ apt list jackd jackd2 qjackctl
  Auflistung... Fertig
  jackd2/focal,now 1.9.12 ~dfsg-2ubuntu2 amd64 [Installiert,automatisch]
  jackd2/focal 1.9.12 ~dfsg-2ubuntu2 i386
  jackd/focal,focal,now 5+nmu1 all [installiert]
  qjackctl/focal,now 0.5.0-1ubuntu2 amd64 [installiert]

With QjackCtl I was able to activate the "Realtime" function of Jack.

* priority to the sound.

* etc...

How do I set this?

You should have installed the latest ALSA, Pulse audio, JACK2, etc...

All this is available.

Thanks!

[jujudusud]

For information, LibraZiK switches to version 3. https://librazik.tuxfamily.org/doc3/manuel/noyau
Your memlock should be "unlimited"
Rtprio I would prefer to set it to 90 and Nice to 15...
https://man.archlinux.org/man/limite.conf.5

Uname -a instead of -r

What about the CPU frequency scaling ?

What about the swapiness ?

[lorbeerbund]

For information, LibraZiK switches to version 3. https://librazik.tuxfamily.org/doc3/manuel/noyau

Thank you!

Your memlock should be "unlimited"
Rtprio I would prefer to set it to 90 and Nice to 15...
https://man.archlinux.org/man/limite.conf.5

/etc/security/limits.conf now:

@audio           -       rtprio 90       #99
@audio           -       memlock unlimited
@audio           -       nice 15

Uname -a instead of -r

• ~$ uname -a
  Linux regenbogen-main 5.8.0-50-generic Add the description paper to the wiki #56 ~20.04.1-Ubuntu SMP Mon Apr 12 21:46:35 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

What about the CPU frequency scaling ?

• ~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
  powersave
• ~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
  performance powersave
• ~$ echo performance | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
  performance
• ~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
  performance

What about the swapiness ?

• ~$ swapon -s
  NAME TYPE SIZE USED PRIO
  /swapfile file 2097148 0 -2
• ~$ sysctl vm.swappiness
  vm.swappiness = 60

Should I change it?

[jujudusud]

So, your kernel is not Build to be preemptible.
You should consider to use another one or build your own.
Considering 5.4 is the latest long terme service kernel available, please test with the low latency librazik one.

Swapiness, preferable to use 10.
When your RAM is 90% full, then swap is enable. Not before.

[lorbeerbund]

Now I booted an Ubuntu studio via USB live system, installed Jamulus here and let me connect to a server. Ad hoc significantly better results in the quality of the sound and the transmission. However, a permanent Overall Delay of over 120 ms. Auto Jitter Buffer locally and server-sided at 8 and buffer size 42.67 ms (1024).

And yes, in QjackCtl at Frames/Period the value 1024 is entered, which results in a latency of 42,7 ms (at a buffer size of 2). If I change Frames/Period to the known value of 128, I get a latency of 5,33 ms. But then the glitches are there again. This encourages me to experiment with the Frames/Period value under Mint too.

Greetings

[jujudusud]

With a USB interface, periods should be 3 not 2. With 3 periods, you will be able to reach 128 frames.

[lorbeerbund]

Well done. After all our measures, now we've found a good compromise between quality and low latency. I achieve the best result with a frames/period value of 256, which results in a latency of 10.67 ms and an Overall Delay of about 50 ms. The delay is acceptable and the quality is quite good, no more noise and distortion.

Thank you all for your active support on this tricky journey!
lorbeerbund