JamKazam Forums
"enough bandwidth to send you a degraded, but sufficient, audio stream." - Printable Version

+- JamKazam Forums (https://forum.jamkazam.com)
+-- Forum: Jamkazam Forums (https://forum.jamkazam.com/forumdisplay.php?fid=1)
+--- Forum: Help with Network Gear (https://forum.jamkazam.com/forumdisplay.php?fid=3)
+--- Thread: "enough bandwidth to send you a degraded, but sufficient, audio stream." (/showthread.php?tid=2063)



"enough bandwidth to send you a degraded, but sufficient, audio stream." - ellis@hillinger.org - 03-11-2021

I'm trying to understand the diagnostics JamKazam provides so that I can equate them to the bandwidth available for our sessions.  The typical case is two players with wind instruments.  One player has 25 Mbps download and 14 Mbps upload, while the other has 90 Mbps download and 18 Mbps upload speeds.  This is far more than the 1 Mbps minimum that JamKazam published: https://forum.jamkazam.com/showthread.php?tid=114.  (Really?)  We have not analyzed the traffic from other users on these connections, but since our results have been consistent during different sessions, this doesn't appear to be the determining factor.  We are both using current Windows 10 systems and Focusrite Scarlett USB adapters.

My question is about bandwidth, not latency, but I should note that we are having challenges with delay.  We are about 100 miles apart, and one of the players is on an island.  The challenges of providing service at that remote location seems to push the total latency above 50 ms.

Our results with this configuration are generally stable, although there are some artifacts (especially on high notes) that are of concern.  When we examine the "Audio Bw Rx" status it usually says <other player> "has enough bandwidth to send you a degraded, but sufficient, audio stream."  While I haven't found documentation about this specific message, the documentation (https://jamkazam.freshdesk.com/support/solutions/articles/66000457796-understanding-session-statistics-diagnostics) says this shows the size of the audio stream and that these will be automatically adjusted.

What exact parameters is JK looking for, and what does it means by "enough bandwidth" in this situation?


RE: "enough bandwidth to send you a degraded, but sufficient, audio stream." - Zlartibartfast - 03-11-2021

I'm not in a position to give you a definitive answer, but I'll try to be of help.

"enough bandwidth" is basically just that - enough to get you connected. But - if you want to have a clear, steady, reliable connection, then more than "enough" will be needed. It sounds like there is either an underwater cable or a land-based wireless link in your internet chain. If it's the former, then that cable might be an old link with limited bandwidth, or it could be a new fiber cable, which would not be a problem in most cases. If the link is wireless, then it could be an impossible task to get a better session connection.

So, even if you had gigabit fiber service at your house, it wouldn't solve the problem in that scenario.

There can be other reasons to get bottlenecked on the internet. Different transport methods, different traffic priorities,, different routes, on and on. I've found it works best if you can exceed the minimum Jamkazam requirements by 5x or better. All of the successful sessions I've had over the last 3 months were with people who were on a minimum of 5Mb/s upload and 50Mb/s download (the upload speed is much more important). Either cable service or fiber optic. DSL is not that great in many places (runs on analog telephone lines) and wireless in any form is just a disaster IMHO.

in summary, it's not really a simple matter of speed. it's Quality of Service that matters.


RE: "enough bandwidth to send you a degraded, but sufficient, audio stream." - ellis@hillinger.org - 03-11-2021

Thank you for that Zlartibartfast. As a former network engineer I understand what you're talking about, but my question is more specific. Absent latency and jitter issues (those show up elsewhere in the diagnostics) JK is saying the bandwidth is insufficient, even during an idle session. What is JK looking at and what does it deem to be sufficient bandwidth?


RE: "enough bandwidth to send you a degraded, but sufficient, audio stream." - Zlartibartfast - 03-11-2021

I don't know the answer to that. I do know that my system, which is about as tight as a (insert metaphor here) still fails the network latency test, yet in real-world usage I have system latency below 3ms, buffer bloat almost zero, & WAN latency stays below 30ms most of the time. How can I still fail the JK latency test?

It's because the test is flawed, I think. So I'm not confident that the metrics reported by the JK client are accurate.


RE: "enough bandwidth to send you a degraded, but sufficient, audio stream." - StuartR - 03-12-2021

(03-11-2021, 05:57 PM)ellis@hillinger.org Wrote: Thank you for that Zlartibartfast.  As a former network engineer I understand what you're talking about, but my question is more specific.  Absent latency and jitter issues (those show up elsewhere in the diagnostics) JK is saying the bandwidth is insufficient, even during an idle session.  What is JK looking at and what does it deem to be sufficient bandwidth?
Internet capability to handle real time audio data to and from multiple clients in a timely manner (20 msecs or less) is difficult to obtain and even more difficult to predict. When you add the inherently poor capabilities found in most home routers and the lack of default audio processing capabilities in Windows systems you're asking for a frustrating and hard to diagnose problem. Our band has experienced all of these issues over the last year using Jamkazam and finally threw in the towel. While we fixed our router issues, our audio interface and Windows issues, we couldn't overcome the high latency routes between our multiple ISPs, even though we were geographically close to each other. It's a daunting challenge which gets in the way of doing what we started out to do - enjoy playing music together.


RE: "enough bandwidth to send you a degraded, but sufficient, audio stream." - WernerLohe - 03-17-2021

(03-12-2021, 04:54 PM)Yep; I threw in the towel, too. (....just occasionally look at one of these threads to see if the laws of physics have changed.). It\s hard to give up hope, though. I'm thinking to see if a hotspot (or even my phone?) wired to my computer will work better than my fully hardwired connection..... Wrote:
(03-11-2021, 05:57 PM)ellis@hillinger.org Wrote: Thank you for that Zlartibartfast.  As a former network engineer I understand what you're talking about, but my question is more specific.  Absent latency and jitter issues (those show up elsewhere in the diagnostics) JK is saying the bandwidth is insufficient, even during an idle session.  What is JK looking at and what does it deem to be sufficient bandwidth?
Internet capability to handle real time audio data to and from multiple clients in a timely manner (20 msecs or less) is difficult to obtain and even more difficult to predict. When you add the inherently poor capabilities found in most home routers and the lack of default audio processing capabilities in Windows systems you're asking for a frustrating and hard to diagnose problem. Our band has experienced all of these issues over the last year using Jamkazam and finally threw in the towel. While we fixed our router issues, our audio interface and Windows issues, we couldn't overcome the high latency routes between our multiple ISPs, even though we were geographically close to each other. It's a daunting challenge which gets in the way of doing what we started out to do - enjoy playing music together.



RE: "enough bandwidth to send you a degraded, but sufficient, audio stream." - Zlartibartfast - 03-17-2021

adding a wireless link to the data chain can only increase latency. This includes 5G, Bluetooth 5, WiFi 6, and subspace carrier waves.

Since Quantum-Entangled ethernet doesn't exist yet, the best choice for WAN (if you have it) is fiber optic. For LAN, Cat5e is sufficient, but a 5 year old router is probably due for an upgrade.


RE: "enough bandwidth to send you a degraded, but sufficient, audio stream." - ellis@hillinger.org - 04-05-2021

Thinking about the issues we've encountered with JamKazam, I would appreciate your ideas about the appropriate use of this product.

Looking at the JK website and the material they publish, they focus first on rehearsals and education; live broadcasts show up further down the list. In my experience the product does work for rehearsals, but when we push it to produce something to share we run into challenges or have to augment it with other tools.

Should we differentiate two classes of JK users: those needing a low latency solution to provide a reasonable rehearsal environment, and those trying to produce recording for public performance? If that's the case, can we define different sets of requirements for these different classes of users?
=> Public performance environments require very low latency, high bandwidth (100+ Mbps) and high quality audio equipment (audio adapters, quality mics, etc.)
=> Rehearsal environments and amateur users can get by with slightly greater latency, moderate bandwidth (~20 Mbps) and simpler audio equipment such as USB mics and no audio adapter.
Would this be a better way to explain to users what the requirements for JK really are?


RE: "enough bandwidth to send you a degraded, but sufficient, audio stream." - Zlartibartfast - 04-09-2021

Good question.

It's sort of like when someone is looking at manufacturer's specification for a car or computer or stereo system (or just about anything)

Usually you get to know the minimum requirements and the (theoretical) maximum capabilities, and you have to use some critical thinking to discern how it will work for you. And of course, optimism draws us in. Later, we get some "real world" stats.

YMMV as they say.

And, this platform is STILL a work in progress. It's safe to assume that if you want everything to work as best as possible, you will need to start with the best internet service, computer, interface, etc. that you can afford.

BTW the video feature of JK is going to be re-built, and if it's not working for anyone now, well, it won't until such time as the new code is released, so don't waste your ime trying to "fix" it.