Should the Jamulus server use multiple UDP ports to combat jitter?

[hselasky]

Hi,

I'm the author of HPSJAM, See https://github.com/hselasky/hpsjam . I recently made an interesting discovery, that the biggest enemy for low latency audio is Jitter and not packet loss.

The internet is connected not only using one physical connection, but many. The IPv4- and IPv6- address and UDP port numbers are used to select on which physical fiber your application traffic is put. Also inside routers, traffic is split up into multiple so-called per-CPU queues, using the exact same principles. When using fixed address information it is called a stream and packets are processed in sequence. When using variable address information it is called a multi-stream.

When many applications output data at the same time, the streams that end up on the same packet queues and physical fiber links may overflow at random points in time causing random Jitter. But not for all queues at the same time.

By using multi-UDP streams (15-ports) allowing up to one of three packets to get delayed or lost, low latency applications end up with much higher overall quality and stability I've found. In HPSJAM there is now a GUI button to select single- or multi- port and the difference is quite noticable.

I was wondering if Jamulus could do something similar? I've used 15 ports, because the sequence number spins around 255, because that makes sense for the 1/3 packet loss too.

Packet 1 goes to port+0, packet 2 goes to port+1 and so on, until it repeats.

Any comments?

--HPS

[ghost]

This is interesting research. I think it is good to keep this optional because there may be Pros and Cons depending on the situation. There may be other similar methods that work also. I 'just thought now' that the server could assign different unchanging ports for different clients for a similar effect. Note that Jamulus needs to be a good internet citizen, and not look menacing either, to avoid negative attention.

[hselasky]

Using 15 UDP ports per server is not any issue. There are plenty of UDP ports to take from!

[pljones]

That requires at least a 15 packet buffer length, to allow for out of sequence arrivals, to avoid loss, though, doesn't it? If there's, say, three packets of random jitter on each queue additional buffering for that fifteen lots of jitter will get added on top of the 15 packets inherently required for sequencing. So that adds up to more latency, surely?

[hselasky]

@pljones :

I just use 3x1ms HPSJAM packets for out of sequence arrivals. There are some magic constants in there.

It has something to do with statistics and randomness. It's not directly logical.

HPSJAM allows 1/3 of packets to dissappear, unlike Jamulus. Which means HPSJAM takes the first 10 packets out of 15, before it starts producing sound. If the 10 best links out of 15 have similar latency, it adds no more than 3 ms of delay on RX.

For example a 3 ms HPSJAM frame looks like this:
PKT 1 - data
PKT 2 - data
PKT 3 - redundancy (xored data 1 and 2)

Supposedly the three packets go on different links and we pick the 2 first packets (any of the 3) which allows for full audio reconstruction.

This repeats 5 times for the 15 ports.

--HPS

[hselasky]

So would a single 150 channel server still only listen for packets on the one port or would it need 2550 ports? Responses to each client would need 15 ports, so 2250 there. And if I were running 15 servers on a single static IP, that would need 33750 ports (rather than 2550)?

Using HPSJAM only the server side use multiple ports. The client side only use a single port. This is due to the firewall / NAT issue, then if the client use multiple UDP ports instead, then the server would need to track that, which is more overhead.

All HPSJAM clients send data to the same 15 server ports. When you connect you only give the first UDP port, and it is assumed that the other 15 are there. It is also assumed that the first connect packet goes on UDP port N+0.

This is also good for load balancing, that now you can receive UDP data on multiple threads, and not only at the application level, but also at the kernel level, you utilize more hardware queues. This is good for lower latency. I know that different OS'es behave differently there, but the principle is the same.

[pljones]

Using HPSJAM only the server side use multiple ports. The client side only use a single port.

Ah right. So the 15 ports on the server are shared by all clients and it's still just one response port per client. OK. (So only more ports than Jamulus server on the incoming side.)

[hselasky]

Are there any official servers available?

Not really official server yet, but you can test these if you don't have server access:

5.onj.me:34343 (Located at server location in the UK)
home.selasky.org:700 (Located privately in Norway, This one also has a synth and reverb connected on MIDI channel 1, 2 and 3. Avoid program change events, because it's not really GM compatible :-)

--HPS

[hselasky]

Using HPSJAM only the server side use multiple ports. The client side only use a single port.

Ah right. So the 15 ports on the server are shared by all clients and it's still just one response port per client. OK. (So only more ports than Jamulus server on the incoming side.)

Yes, correct!

[hselasky]

Using HPSJAM only the server side use multiple ports. The client side only use a single port.

Ah right. So the 15 ports on the server are shared by all clients and it's still just one response port per client. OK. (So only more ports than Jamulus server on the incoming side.)

Yes, correct!

To ensure no packets are lost in the firewall, I always respond from the UDP N+0 port on the server side the whole first second, while the client is banging N+0..N+15, so that I'm sure the firewall / NAT is ready to receive packets on those other ports aswell. Not a problem for IPv6 though.

[hselasky]

During the last few days I've made a slew of changes to HpsJAM w.r.t. multi-path UDP routing. If Jamulus could do something similar audioquality would improve instantly w/o having to sacrifice any bandwidth. I think you can use my techniques even without redundancy packets. Please give HpsJAM a spin and you'll see the difference. Sorry I don't have time to make patches for Jamulus.

[mcfnord]

"Audio quality would improve without sacrificing any bandwidth."

Is reduced jitter the result?

Would this feature require server operators to open 15 more ports? Would opening these be as seamless as it is for just one port today for registered servers?

It sounds like clients would transmit on one or more of 16 ports, but it also sounds like that's not a big deal (no additional configuration).