Open hselasky opened 2 years ago
AOO which SonoBus is based on uses a single UDP port, mostly to keep NAT traversal simpler. I’d be interested to hear more about your technique’s advantages…
HpsJAM uses 15 ports by default, and uses an 8-bit sequence number which wraps at 255, so that it is a multiple of the number of ports. Only the server side use 15 ports. The client still sends from the same port.
On the internet, routers and traffic exchange points, use the IP and UDP port numbers when switching the traffic on different physical connections. When the UDP port numbers are fixed, this is called a stream, and then if there is a temporary congestion, this leads to jitter for all UDP packets on the same UDP stream.
HpsJAM then divides the traffic into 3 packet types:
1) First frame (contains 1.5 ms of PCM audio) 2) Second frame (also contains 1.5 ms of PCM audio) 3) Redundancy frame (XOR of 1+2)
HpsJAM has a fixed packet rate, 1000pps +/- 0.0001 pps, and adjusts the packet rate a tiny bit to match the actual sample rate of the sending device.
Then HpsJAM uses some statistics to figure out relative delay between the different links and re-map the 15 ports by the following criterias:
1) Arrived too early 2) Arrived on time 3) Arrived too late
Then all the first frames go to "3" ports. Second frames go to "2" ports. Redundancy frames go to "1" ports.
It's like sending packets in reverse order. The result is amazing, almost no jitter.
The protocol also takes advantage of the redundancy frame, that only 2/3 frames must be received before audio processing starts.
Regarding NAT it is no problem at all. I have a 1 second delay before the server starts using return traffic, and that works great. In the beginning only one UDP port is used and this is also selectable in the program!
Best regards, --HPS , author of HpsJAM.
I see you were at LAC 2014. I was at LAC 2015 :-)
Interesting, SonoBus is purely peer-to-peer, there is no server involved in the audio transmission path, so I don't know if what you are doing will be quite as relevant here. But definitely cool!
Actually, that was LAC 2004, I'm getting pretty old now :)
All modern computers, even the ones used on the desktop, have multiple queues for ethernet and WiFi and split the traffic :-) This principle is everywhere on the internet.
So just the act of sending the data to a peer on multiple ports tends to improve the performance of the network transmission, compared to sending the same packets serially to a single port, interesting!
Yes, that's my observation. Either you change both SRC port and DST port or just one of them. IP you cannot change.
Interesting discussion, should this ticket be renamed to something like "[IDEA] multi-path UDP" ?
Hi,
Does Sonobus use multi-path UDP as a transport? Or does it only use a single UDP port?
The reason for asking is that I found during development of hselasky/HpsJam that multi-path UDP is a really good way to reduce jitter. When you do it right the bandwidth is kept constant. Sorry for asking here. Don't know your code that well.
--HPS