SonoBus v1.3.2 released

[Jesse Chappell‏]

Quick bugfix release:
* Fixed bug where input mute/gain was ignored with only 1 input channel

Jesse

[Lucio Mauro‏]

jesse, could you help me with a tip on how to create my own server to use in sonobus?

[Jesse Chappell‏]

If you want to run your own connection server, you will need to get
and build the source code for it at:
https://github.com/essej/aooserver
If you need help building it, let me know what platform you want to
build it for and your experience level.

Also note that the server only handles the user and group connection,
so that users can find the direct addresses to connect to each other.
All audio is sent peer-to-peer and does not go through this server.

The standalone application also provides this server functionality
while it is running, using TCP port 10999, as an alternative if you
want to do port forwarding and use it instead while you have SB
running.

Jesse

> --
> You received this message because you are subscribed to the Google Groups "SonoBus Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sonobus-user...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sonobus-users/2f8d750a-7114-4dbe-925e-cb804b0fd088n%40googlegroups.com.

[Christiaan Roselaar‏]

"All audio is sent peer-to-peer and does not go through this server. " (earlier post by Jesse).

Can someone please explain how this (a peer-to-peer audio connection) is possible in a situation where two Sonobus-users are
a) both situated behind a NAT-firewall;
b) NO Sonobus-specific port-forwarding rules have been set on either one of the routers;
c) UPnP is NOT activated on either one of the routers?

On October 20th last year, the (respected!) autor of Sonubus, Jesse, writes
"In the future, there may be a non-peer-to-peer server based version of SonoBus that will let anyone connect to anyone, at the expense of routing all traffic through an internet server, more like music101 or jacktrip in server hub-mode, jamulus, etc."

Can it be this functionality has been build into the connection-server in the meantime, so the connection-server can act as some sort of fall-back (audio hub-server) in case a peer2peer connection between parties is not possible? (Introducing unwanted latency at the same time?)

Looking forward to your reactions.

Kind regards,

Christiaan Roselaar

Op donderdag 7 januari 2021 om 16:42:46 UTC+1 schreef jesse:

[Randy Petty‏]

See this section which talks about port forwarding

https://www.sonobus.net/sonobus_userguide.html#If-You-Cannot-Connect

Randy

To view this discussion on the web visit https://groups.google.com/d/msgid/sonobus-users/4c770c88-ad53-4fbe-be61-a094e607c68dn%40googlegroups.com.

[Jesse Chappell‏]

Comments below...

On Mon, Feb 15, 2021 at 11:37 AM Christiaan Roselaar <chris...@roselaar.eu> wrote:

"All audio is sent peer-to-peer and does not go through this server. " (earlier post by Jesse).

Can someone please explain how this (a peer-to-peer audio connection) is possible in a situation where two Sonobus-users are
a) both situated behind a NAT-firewall;
b) NO Sonobus-specific port-forwarding rules have been set on either one of the routers;
c) UPnP is NOT activated on either one of the routers?

There are a few different kind of NATs and for years there are standard techniques for getting P2P UDP communication going by doing a packet-sending dance which works on most NATs. The exception are when both sides are on so-called “symmetric NATs” which present different ports for each destination they are communicating with. In this case at least one end would need to do manual port forwarding in order to do P2P at all. If that isn’t possible, you are out of luck with SonoBus right now, until we do implement the fallback relay of packets through a connection server. 

On October 20th last year, the (respected!) autor of Sonubus, Jesse, writes
"In the future, there may be a non-peer-to-peer server based version of SonoBus that will let anyone connect to anyone, at the expense of routing all traffic through an internet server, more like music101 or jacktrip in server hub-mode, jamulus, etc."

Can it be this functionality has been build into the connection-server in the meantime, so the connection-server can act as some sort of fall-back (audio hub-server) in case a peer2peer connection between parties is not possible? (Introducing unwanted latency at the same time?)

That should actually be possible pretty soon, BUT I will not be hosting a public one myself with relaying enabled because I don’t want to pay for that server bandwidth! At that point I will probably make the distribution of the connection server more easily set up so people can stand one up in their cloud server of choice for their own use. Or even easier, in their own house if they have good internet and open up a few port forwardings and want to be a “hub”.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonobus-users/4c770c88-ad53-4fbe-be61-a094e607c68dn%40googlegroups.com.

[Christiaan Roselaar‏]

HI Jesse.
All clear now - I wasn't aware of the "packet-sending dance" phenomenon, that's involved in establishing a P2P UDP connection over a NAT-firewall. Never to old to learn :).
One other question though.
I'm involved in (read: technically supporting) an on-line project from an established Dutch ensemble for contemporary music that goes by the name "Insomnio".
Amongst others, guitar, mandoline and harp are involved and as we already thought, timing and more importantly (low) latency is of the utmost importance for those type of instruments to be able to play together on-line.
We initially took off on the Jacktrip-road using MacBooks and RaspberryPi's as end-points. With good results in situations where end-users/musicians were connected to the internet via Cable-modems or fiber. It was the nerd-type interface of Jacktrip and Jackd that only recently made us move towards Sonobus with its great and very intuitive user-interface.
However, after some test-runs, we're inclining to move back to Jacktrip again since the connections established through Sonobus come no where near the connections established through Jacktrip in terms of (low) latency and jitter.

This morning we had a test-run where we compared Jacktrip and Sonobus. For Sonobus we used two Windows-10 PC's as endpoints. For Jacktrip we used two RaspberryPi 3B+. Using iPerF3, I measured jitter on the connection between the RPI end-points and found that to be around 0.14msec. One-way latency, measured using Ping, ran from one RPI to the other, gave values in the 10 -11msec range. Both jitter and latency-values were found to be consistent over a two hour time frame.
Sonobus, when used over the same network within the same time-frame, reported latencies in the 50-60msec range, and the jitter-buffer needed to be set at 13msec at the least to obtain a drop-out/crack-free connection?

As said, the Sonobus/Win10 end-points and the Jacktrip/RPI3B+ endpoints communicated over exactly the same infrastructure (LAN@location#1, Internet, LAN@location2). The difference in Jitter as measured through iPerf3 and as reported/experienced by Sonobus (buffer-size needed to be more than 13msec) can I.M.H.O. therefore not be related to the network. This is also confirmed by the fact that both RPI's using Jacktrip provided a connection that, in cotrary to Sonobus, did meet the need of the musicians involved in this mornings test-tun.
So, how should we explain our findings? If the network is not the cause, what is? Could the substantial difference in delay/latency and jitter, as experienced when comparing Sonobus to Jacktrip, be related to the difference in Operating Systems used (Raspbian vs. Windows10). Could it be related to chipsets/drivers used for the ethernet/utp-interface on both Windows-PC's? Could it be related to (I don't dare to say this ;) ) bugs possibly present in Sonobus?

I'd very much appreciate your response. And should any additional tech-info be required, please let me know.

Not to press you (I know it's all volunteer work what you're doing (same goes for me)), but the Insomnio-ensemble is due for a life performance on Dutch National radio the 28th of March and we'd just love the idea to then be able to do this performance using Sonobus.

Hope to hear from you & kind regards,

Christiaan Roselaar
MSc E.

Op maandag 15 februari 2021 om 18:27:14 UTC+1 schreef jesse:

[Jesse Chappell‏]

That's a lot of variables! First of all, there are most likely some
internal implementation issues in SonoBus preventing the minimum
latency from being as low as possible... some of which are going to be
looked into.

Secondly, you should be able to install SonoBus on your RPI boxes
using snap: https://snapcraft.io/sonobus , or using the deb package
maintained by the developer of th Jambox distribution:
https://github.com/kdoren/jambox-debs . Then you can at least take the
Win10 variable out of the equation (esp since you didn't specify what
audio interface/drivers/audio settings you were using on windows)...

Jesse

[Christiaan Roselaar‏]

Hi Jesse.
Thanks for your suggestions/feedback.
Since your last message, I've ran some tests with Sonobus on RPI (Jambox-distro).
It seems Sonobus on RPI works better in terms of jitter/latency than on MacBook. This surprises me, since I'm running the tests over the same network? Only thing I can think of is that the network-interface/driver on MacBook and RPI differ in performance.
Now a question. When running SonoBus, it reports Jitter and Latency. "Latency" is reported for both the outgoing and the incoming connection. These values added are reported as the round-trip latency. Latency- values as reported by Sonobus are however roughly twice as large as those reported by Ping. Consequently.
F.I. when running a test from our home (fiber,100Mbps) to that of my friends (100km away, VDSL, 100Mbps, both same provider KPN) Ping says 13msec. As you undoubtedly know, Ping reports round-trip latency. SonoBus however reports 12msec outgoing, 13 msec incoming latency. 25msec round-trip latency. Roughly twice the value as reported by SonoBus. Could this be a mere matter of erroneously reporting the actual latency? Or does the SonoBus app introduce (so much) additional latency? B.t.w. audio-buffer on both ends is set to 64 samples, 1.3msec). Help...
Another thing is jitter. iPerf3 consequently reports less than 1msec of Jitter between both end-points. When running SonoBus in "manual" mode, the Jitter-buffer however needs to be set at 3msec to get an acceptable quality connection. When putting SonoBus in "auto" mode, the jitter-buffer keeps creeping up to 6 - 8 msec value.
To make a long story short: Jacktrip does the job using the same RPI setup, SonoBus does not (yet) and I don't understand why. And the musicians of Insomnio, the Dutch contemporary music-ensemble I'm assisting on technical matters, now have seen SonoBus and (very much) prefer the SonoBus GUI over the Jacktrip command-line interface.
Help.....

Kind regards,

Christiaan Roselaar

Op woensdag 24 februari 2021 om 17:42:45 UTC+1 schreef jesse:

[Mike O'Connor‏]

i heartily second Christiaan's remarks.

a friend and i were working on getting him going on Sonobus last weekend (and plan to get together again tomorrow).  we're about 10 ms apart, fiber the whole way, jitter's around 1.5ms.  we worked at the same ISP back in the day and know that our network-performance readings are pretty close.  we could get Sonobus down to reporting 45ms roundtrip (20ms each way) with really aggressive settings and the jitter buffer of floated around 5-9 ms required to get a clean signal.  i agree that the UI is terrific.  i would love to find out that Sonobus is just *calculating* latency wrong -- and that we are getting faked out by those readings and thus never actually try to play because we think the latency won't let us.  :-)

--
You received this message because you are subscribed to the Google Groups "SonoBus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonobus-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonobus-users/4f447d5e-79a7-41b4-bbda-efcee28bd386n%40googlegroups.com.

[Randy Petty‏]

This is why I'm now exploring Ubuntu and the associated Sonobus install for it.  My only issue using Sonobus is drum backing tracks, played from within Sonobus, have enough dropouts to interrupt our jam sessions.  We don't seem to notice this for others who are playing instruments and singing.  It manifests itself as a sound like someone is rapping on their microphone.  Current platform is Windows 10 on a decent laptop.

[Doal Miller‏]

Sounds like you have a pretty good connection. I had tried using Sonobus with a friend of mine and my ping is around 17-20 and round trip ~44. My friend’s numbers are a bit worse, but it would seem the latency should be OK. Our quality has been great, almost no dropouts. I’m on a Mac and my friend is on Windows 10. However, we just feel the latency is too much so we switched back to Jamulus. The latency seems better with Jamulus, BUT we get dropouts and at times the pops are very loud. With Jamulus I’m running a server on Ubuntu in the cloud.

Don’t know this info helps but it’s just my experience. 

To view this discussion on the web visit https://groups.google.com/d/msgid/sonobus-users/8751c504-9358-486d-a571-b5ad05e7b15cn%40googlegroups.com.

[Marcin Pączkowski‏]

AFAIU SonoBus (or JackTrip or similar) latency will never be close to "ping" time - the data needs to be buffered on both ends. I'm just a SonoBus, but in my experience it doesn't seem to me like the latency calculation is wrong.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonobus-users/8751c504-9358-486d-a571-b5ad05e7b15cn%40googlegroups.com.

[db‏]

We have used both Sonobus and Jacktrip via Virtual Studio servers. The latency time reported by Sonobus was nearly double of that reported by Jacktrip, however we were able to play more in sync using Sonobus. So I suppose they use different criteria for reporting latencies. 

On Mar 6, 2021, at 4:17 AM, Mike O'Connor <oconn...@gmail.com> wrote:

i heartily second Christiaan's remarks.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonobus-users/E9FFF684-588C-4193-9180-214F4917C245%40gmail.com.

[Tony & Celia Becker‏]

SonoBus reports latency in a very straight-forward way.  (no-spin)