02-09-2022, 07:30 PM
I was using DOCSIS 3.0 cable service at my previous residence - it was fine. I now have fiber optic to the premise, which is a bit better in terms of jitter. However, cable service is typically adequate. The big bug-a-boo here is that all jitter is cumulative. The jitter that may be from your computer/interface added to jitter from the network connection added to the same factors from everyone in the session can make things ugly pretty quick.
Re: network tests - http://www.dslreports.com/speedtest - will provide info about ping times and "bufferbloat" (which is an issue that you have limited control of).
in Terminal, run this command:
MacBook-Air:~ yournamehere$ ping 8.8.8.8 -t 30
(you are pinging a free DNS server from Google)
here's the results from my Macbook (on WiFi):
--- 8.8.8.8 ping statistics ---
30 packets transmitted, 29 packets received, 3.3% packet loss
round-trip min/avg/max/stddev = 20.658/29.151/132.108/22.084 ms
you can see the effects of extreme jitter, expressed as the stddev value. You can also see that 1 out of 30 packets never made it back to me. If you get numbers like this, then you can pretty much forget about using JamKazam on that computer (the one I use is a Mac Mini with integrated ethernet, not this Air).
And I wonder why your network adapter is an external one - the laptop doesn't have one built-in? this is definitely something to look into. USB (assuming it's USB) performance can be all over the map. Drivers matter, firmware revisions matter, it even matters which port you plug into because there's a pecking order in the USB hierarchy (with the USB host controller being 1, and then other devices down the line).
Anyway the point is there are lots of pieces to the puzzle. I don't think your cable modem is a source of trouble, but then how many connections are sharing your node? if you live in apartment where most tenants are on cable service, you're sharing your internet node with most if not al of them (not a bandwidth issue here - a latency issue).
Next time you're looking a performance info in a session, look to see the details of where the yellow indicators are showing up. CPU? Device (audio I/O) latency? network jitter?
Re: the metronome issue - the JK click is "closest" to the "middle of the room", and therefore *should* be heard at about the same time for all session players. If one player is "hosting" the click, that's likely to be heard sooner by the host that other members of the session. So using the JK metrnome *should* have better results.
Finally, Jamkazam can either be peer-to-peer (the original way) or ARS (the new way) I found that ager the ARS system went online, I was ale to jam in a 3 piece session where one member was over 900 miles away on fairly crappy internet service, and the other member was about a mile from my house. This had not been possible using the P2P network option in Jamkazam.
I'm not a doctor, but I play one on TV ;-}
Re: network tests - http://www.dslreports.com/speedtest - will provide info about ping times and "bufferbloat" (which is an issue that you have limited control of).
in Terminal, run this command:
MacBook-Air:~ yournamehere$ ping 8.8.8.8 -t 30
(you are pinging a free DNS server from Google)
here's the results from my Macbook (on WiFi):
--- 8.8.8.8 ping statistics ---
30 packets transmitted, 29 packets received, 3.3% packet loss
round-trip min/avg/max/stddev = 20.658/29.151/132.108/22.084 ms
you can see the effects of extreme jitter, expressed as the stddev value. You can also see that 1 out of 30 packets never made it back to me. If you get numbers like this, then you can pretty much forget about using JamKazam on that computer (the one I use is a Mac Mini with integrated ethernet, not this Air).
And I wonder why your network adapter is an external one - the laptop doesn't have one built-in? this is definitely something to look into. USB (assuming it's USB) performance can be all over the map. Drivers matter, firmware revisions matter, it even matters which port you plug into because there's a pecking order in the USB hierarchy (with the USB host controller being 1, and then other devices down the line).
Anyway the point is there are lots of pieces to the puzzle. I don't think your cable modem is a source of trouble, but then how many connections are sharing your node? if you live in apartment where most tenants are on cable service, you're sharing your internet node with most if not al of them (not a bandwidth issue here - a latency issue).
Next time you're looking a performance info in a session, look to see the details of where the yellow indicators are showing up. CPU? Device (audio I/O) latency? network jitter?
Re: the metronome issue - the JK click is "closest" to the "middle of the room", and therefore *should* be heard at about the same time for all session players. If one player is "hosting" the click, that's likely to be heard sooner by the host that other members of the session. So using the JK metrnome *should* have better results.
Finally, Jamkazam can either be peer-to-peer (the original way) or ARS (the new way) I found that ager the ARS system went online, I was ale to jam in a 3 piece session where one member was over 900 miles away on fairly crappy internet service, and the other member was about a mile from my house. This had not been possible using the P2P network option in Jamkazam.
I'm not a doctor, but I play one on TV ;-}