[HN Gopher] Show HN: Low-latency jamming over the internet
___________________________________________________________________
Show HN: Low-latency jamming over the internet
Author : weepy
Score : 175 points
Date : 2021-10-23 13:27 UTC (9 hours ago)
(HTM) web link (sub.live)
(TXT) w3m dump (sub.live)
| koopuluri wrote:
| Wow. I really like the positioning of your product: the audience
| and value proposition are crystal clear.
|
| I'm going to share this with my musician friends and see what
| they have to say. I know they had challenges jamming at the start
| of the pandemic lockdown that stemmed from a) variance in
| internet connection strengths and b) innate latency in Zoom.
|
| All the best & kudos for launching!
| PaulDavisThe1st wrote:
| I'm guessing that most people reading this are not familiar with
| some of the other options available for this kind of thing. In
| particular, they likely don't know about Sonobus:
|
| https://sonobus.net/
|
| (and that's likely because it's libre software and the developer
| doesn't really do marketing)
| [deleted]
| arctan5x wrote:
| Checkout https://jacktrip.org/studio.html. We enable low latency
| audio connection through open source technology developed at
| Stanford. We can scale to hundreds of users signing at the same
| time. Check out hundreds of choir members signing together
| https://www.youtube.com/watch?v=SJgB5QmyDfU.
| [deleted]
| capableweb wrote:
| Would be amazing if this could be released as a Linux binary as
| well. Me and many of my friends are on a P2P mesh network, I'm
| sure we can push the latency down to below 20ms which would be
| amazing to see/hear!
| weepy wrote:
| Within the same city you can get <5ms
| alberth wrote:
| >"We've been able to achieve sub _20ms_ latency from UK to
| Denmark - more than 1000km"
|
| It's pretty solid given that the speed-of-light would like 3.3ms
| to travel that same distance.
| darepublic wrote:
| Curious about using this to stream a jukebox playing analog
| records to myself
| capableweb wrote:
| You can achieve that with a much simpler solution, look into
| RTMP.
| weepy wrote:
| you could but you don't need higher latency.
| lwansbrough wrote:
| One thing you might be interested in is a company called
| NetworkNext. (No affiliation, I just think it's a great idea.)
| They provide a private network marketplace that will give you
| pretty much optimized latency anywhere in the world.
| NikolaNovak wrote:
| One of the concerns I always have about things I love is that
| they'll work but eventually disappear. Is there a way to
| donate/pay/tier for this? I assume it comes at non-zero cost to
| you in terms of time bandwidth hosting etc.
| capableweb wrote:
| Development is never free, but this seems to be driven by a P2P
| protocol so hosting/bandwidth costs should be close to zero
| (maybe signalling server is hosted by creator but should be
| relatively cheap to host). I agree that donation would be nice,
| but won't prevent it from disappearing. Only solution I can
| think of to completely make it unable to disappear would be to
| open source the code base, either now or having a guarantee
| that the code base would be open sourced if the author looses
| interest.
| weepy wrote:
| There's a "buy me a coffee" on the page if you're feeling
| generous! It's true the cost is certainly the dev time not so
| much the servers. Though open sourcing doesn't protect things
| from dying - it's people not using them!
| capableweb wrote:
| Awesome! If Linux binaries become available I'll for sure
| "buy you a coffee" :)
|
| Open sourcing is more to enable people to be able to build
| the thing in the future with new libraries. OSes move
| forward every day and something that runs/builds today
| might not be able to run/build tomorrow, so open sourcing
| makes sure it's possible to change libraries/API usage if
| needed.
| k__ wrote:
| I don't get these realtime collaborative streaming services.
|
| Streaming at home via wifi is already crappy, how should this
| ever work with more distance?
| erik_p wrote:
| Well you get that there a need for it, and people are trying to
| find solutions to overcome the issue of latency, that's the
| whole point, isn't it?
| capableweb wrote:
| Don't use WiFi? Ethernet has way less latency. Combine with
| everyone being in the same city/region and using fiber network
| and latency should be really good.
|
| Otherwise, find friends that you have visibility with and setup
| a P2P WiFi via antennas/radios, you'll get insanely good
| latency.
| k__ wrote:
| Yeah, I shouldn't use tech that is basically used all over
| the world for convenient internet connections to access a new
| tech that is basically built on top of that.
|
| Sounds reasonable...
| capableweb wrote:
| The suggestion of a P2P mesh is only if you physically
| could set that up.
|
| Otherwise, using Ethernet + Fiber connection should be good
| enough for most. Only if you really wanna lower the latency
| should you invest in additional hardware.
| weepy wrote:
| You can play with Wifi - it's OK - but you get probably
| 5-10ms better latency with Wired LAN. Also I think you
| have a lower tolerance for latency of your own actions vs
| the latency of another person's.
| wmwmwm wrote:
| Wifi might not be too bad, though it can spontaneously
| degrade badly if you get interference. Not great in the
| middle of a jam!
| erinaceousjones wrote:
| "This won't work with the commodity technology I use"
| (wireless LAN)
|
| "Here's some ways in which it can work using a slightly
| different but still as widely used commodity technology"
| (wired LAN)
|
| "No, that is unreasonable, wires are unreasonable"
|
| Like, it's SUCH a simple solution: use wires. That's how I
| can stream games from my computer to my parent's house at
| 1080p60 with only about 30ms latency over domestic
| broadband connection, for example.
|
| Also, sometimes you can get really lucky with wireless on
| 5ghz - see streaming in VR as a prime example. The
| developer of Virtual Desktop for the Quest has done some
| great work getting a really solid low latency VR feel; I've
| been able to stream games from rent-a-VM ShadowPC servers
| without feeling the lag.
|
| OK, so pro audio is a different beast and is even more
| sensitive to latency than VR, but here people are having
| fun with this tech and clearly it's working for them!
| k__ wrote:
| How is 30ms remotely a good latency here?
|
| I have 14ms between my Quest/PC and it feels sluggish.
| capableweb wrote:
| From the website:
|
| > We've been able to achieve sub 20ms latency from UK to
| Denmark - more than 1000km !
|
| That is pretty good latency for what it does, it's not
| just ICMP packages but sending/receiving audio and then
| all that comes with it.
|
| How are you connecting your Quest and PC? Sounds awful,
| my latency to friends outside the city has a shorter
| latency than that and they are more than 10km away from
| me.
| k__ wrote:
| That's why I don't believe those numbers.
|
| All I've seen in shorter distances was usually worse :(
| capableweb wrote:
| Maybe because you refuse to use wires and instead use
| WiFi which can have really bad latency? If you really,
| really, really want to use WiFi, get a dedicated
| PCIe/external WiFi optimized for latency and you can get
| close to Ethernet latency.
| [deleted]
| grepfru_it wrote:
| this right here.
|
| 1 mile away, both of us have AT&T fiber, we're seeing
| 10-15ms response times (packet size ~1400).
|
| 100 miles away, both on AT&T fiber clocked in around
| 18-20ms
|
| 1 mile away, one on AT&T fiber the other on Comcast
| gigabit had response times around 24ms
|
| 100 miles away, one on AT&T fiber the other on Comcast
| gigabit had response times around 35ms
|
| i'm hard pressed to believe you will find an american ISP
| that prioritizes low latency. verizon 5g home actually
| did some magic with their non-standard hardware where i
| was seeing 9ms to my in-town datacenter and 16ms to my
| out-of-state datacenter. when they replaced the hardware
| with the standards-compliant generation of hardware my
| latency increased to 30ms in-town (they also changed
| towers so that could be part of the problem, plus
| congestion during prime time)
|
| i just moved where i am 6 blocks away from my friend who
| i did the 1 mile test with. i will retest this afternoon
| and update this comment
| weepy wrote:
| That sounds really crazy bad. Europe here so I don't know
| much about US - but I've had US people use it an report
| good experience - so dunno.
| wmwmwm wrote:
| I see 3ms ping times between my friend and I on opposite
| sides of London, though we're both on pretty decent
| broadband tech (me gfast, him some fancy hyperoptic
| plan). IIUC there are some ADSL technologies that add
| some minimum latency floor of 10+ ms. However the long
| distance stretches of backbone fibre shouldn't
| necessarily add too much latency - e.g 100km of fibre at
| 2/3rd speed of light is an additional 1ms on your (two
| way) ping time
| wmwmwm wrote:
| It's worth remembering that sound takes 3ms to travel a
| metre. If you're standing a few metres away from a
| drummer then the round trip time is already pushing 20-30
| ms of latency and yet you can still play together in a
| rehearsal room
| rytill wrote:
| It's impossible to get some people to use wires. I work
| in an area where a high bandwidth, low latency connection
| is in theory mission critical for my customers and they
| still use WiFi 80% of the time.
| bob1029 wrote:
| > It's impossible to get some people to use wires.
|
| Indeed. Perhaps we don't worry about those people
| anymore. If you are interested in a high quality
| experience but don't want to satisfy the prerequisites,
| you are not entitled.
|
| WiFi is never going to provide a reliable, ultra-low-
| latency streaming experience _for the average person_.
| This isn 't a "we can but we won't" type of problem
| where, with just a bit of extra effort, we can somehow
| magically solve all of the deficits.
|
| Yes, there are scenarios where WiFi is indistinguishable
| from ethernet, but those are exceedingly rare in my
| experience.
| NikolaNovak wrote:
| I mean, ethernet/wired IS, also, a convenient standard tech
| used all over the world. There's any number of convenient
| tech out there, and not all of it is for every purpose. My
| Minivan is supremely convenient ubiquitous tech for my kids
| & family but I wouldn't use it on a racetrack. My WRX is
| fun for rallies but I wouldn't use it to haul cargo. My
| phone is a great convenient ubiquitous camera but I
| wouldn't use it to capture professional wedding events.
| etc.
|
| WiFi is indeed a convenient tech used all around the
| world... for _convenience_ , not performance. If you're
| gaming, if you need security, if you need reliable and
| consistent performance, Ethernet is pretty ubiquitous. I
| have couple of wires from Bell router to gaming and music
| computer at home, wifi for other usages.
|
| When added to your extremely sarcastic tone to honest
| attempts to assist... what are you actually trying to
| achieve/learn here?
| k__ wrote:
| The sarcastic tone was because it felt like someone tried
| to help by saying "just replace your convenient
| infrastructure with something much less convenient and
| everything will be okay"
| fragmede wrote:
| I get that wired is less convenient (I'm not going to
| argue the semantics of "most"), but until we can transmit
| power wirelessly _from a distance_ for consumers,
| everyone is still dealing with wires to charge their
| devices. (Even if you have wireless charging, it 's still
| not at a distance and you have to get it just right on
| the charging pad.)
|
| Trying to convince everyone else that something as simple
| as plugging a wire in, is horribly onerous, when they do
| it every day or so, is probably going to be an uphill
| battle, especially if it's for something people want.
| Where jamming with friends over the Internet ranks in
| your list of desires, vs never ever having to do this
| _horrible_ act of plugging in a wire, is on you.
| NikolaNovak wrote:
| But that's exactly true. It's a matter of what you are
| optimizing for - convenience or performance.
|
| There's any number of things WiFi isn't the perfect
| answer for.
|
| Ultimately, in today's world, if you want to jam with
| musicians not in your room, _some_ non zero effort will
| be required. Presumably you have setup you audio
| interface, music interface, microphones, software, mixer,
| midi and asio, etc etc etc... Honestly, for me at least,
| Ethernet is the least inconvenient or nerdy or annoying
| aspect of home studio :-)
| k__ wrote:
| Yes, you're probably right.
|
| For me, cables are a huge issue, because my PC is in a
| room that's not directly connected to my appartement,
| where my internet connection is located.
| enlyth wrote:
| This has not been my experience, with a dedicated PCIe wifi
| card, the difference in latency to when I plug in the
| ethernet cable is about 1ms, if even that, to the point it's
| not worth running cables.
| jagger27 wrote:
| In perfect circumstances, yeah of course WiFi is stable. If
| you live in a dense urban area with tons of WiFi noise
| latency tends to jitter quite a bit. This isn't a problem
| with Ethernet.
| fragmede wrote:
| PCIe (vs USB) is but one of many factors. Which frequency
| is the wifi on? how busy is the spectrum there? What
| features does the router support (MIMO, Wifi 6, etc)? I'm
| happy for you that the difference between wifi and wired is
| 1 ms, but that experience is _far_ from universal.
|
| Ping is also a singular piece of detail. Ping between two
| mediums can change by 1 ms but have a huge effect on
| throughput and jitter? Which affects streaming over the
| Internet a great deal despite not being so obviously
| linked.
| debuggerpk wrote:
| This is revolutionary ...
| iandanforth wrote:
| It would be fun to try to add a predictive layer to this:
|
| - Given the score and what each person has just played predict
| what the next few sounds are going to be - Given a high frame
| rate video stream of a person predict what the next note to be
| played
|
| In the same way that Nvidia has extremely low bandwidth but high
| resolution video enabled by face keypoint tracking and facial
| reconstruction / puppeteering maybe there's a place for
| prediction and/or sound reconstruction from extremely low bitrate
| streams.*
|
| * Obviously not the exact usecase here since a premium is being
| placed on _not_ processing, but still fun to think about.
| emerged wrote:
| I had assumed this would be a VST plug-in so you could integrate
| everyone into (for example) an Ableton Live set with whatever
| other audio/midi manipulation you want.
| capableweb wrote:
| Using audio devices directly makes it possible for any audio
| application to use it, not just applications supporting VSTs.
| Makes it more flexible, not less. A VST could be built on top
| of the current solution, but if it was done vice-versa, it
| wouldn't.
| emerged wrote:
| VST frameworks like JUCE export to VST or stand-alone. So you
| get both for free. Much easier and more flexible.
|
| Also DAWs don't typically allow you to interface with
| multiple audio devices. There are ways of doing it but they
| have major downsides.
| weepy wrote:
| Exactly. I have a prototype VST plugin which pipes the audio
| from the DAW into the application.
| andai wrote:
| Hey, are you using Opus for audio? I remember the whole reason
| Opus was so cool, is that it was the first codec that combined
| low latency with high quality. Most voice chat software uses Opus
| nowadays so I'm surprised to hear existing solutions are so bad.
| weepy wrote:
| Yes Opus - the other benefit is that it can handle a degree of
| missing packets which is very handy.
| fenesiistvan wrote:
| And that feature adds ~20 msec more latency
| weepy wrote:
| You must have set it up wrong. It doesn't add any latency,
| but you do need a higher bitrate to get similar quality.
| prendo1234 wrote:
| Hey @weepy. Awesome project! As a webrtc dev - interested to hear
| about your choices around opus packet durations, FEC percentages,
| ARQ strategies, jitterbuffer length and packet redundancy.
| spmurrayzzz wrote:
| This is very cool (former touring musician turned software
| engineer here!)
|
| I'm curious about the networking/UDP side of this. How are you
| handling retransmits? Do you treat this like a video game would
| and just keep sending the latest data? Or doing something more
| advanced like forward error correction?
| deeblering4 wrote:
| I think https://endlesss.fm got the approach to jamming over the
| internet right.
|
| Instead of trying to reduce latency (which you simply cannot do
| beyond speed of light) endlesss implements a shared "multiplayer"
| 8 track looper.
|
| Jammers add layers to the loop, which has a clock and supports
| sync via ableton live, external audio input, etc.
|
| Plus, every addition to the looper is saved/versioned. You can
| move backwards through loops and export the audio stems. Its a
| great creative tool, and quick way to build on ideas with
| friends.
|
| It's way better than any of the live internet jamming software
| I've used, by far.
| rzzzt wrote:
| NINJAM also works on the same principle:
| https://cockos.com/ninjam/ > The NINJAM client
| records and streams synchronized > intervals of music
| between participants. Just as the > interval finishes
| recording, it begins playing on > everyone else's
| client. So when you play through an > interval, you're
| playing along with the previous > interval of everybody
| else, and they're playing along > with your previous
| interval.
| deeblering4 wrote:
| Ninjam is a bit different, in that its not a looper. The
| timing is offset to keep music sounding in sync to all
| clients, but what you play plays once and does not loop. In
| endlesss phrases will loop until they are changed or removed.
| weepy wrote:
| Endlesss is cool - in fact I know the founder. It's a different
| experience though - when it's live you feel someone else's
| presence compared with offline collab. Up to you what you
| prefer.
| fouc wrote:
| Does anyone know of an alternative that keeps both audio & video
| in complete sync, but possibly pauses/buffers at times in order
| to maximize the segments where everything is kept in sync?
| mgamache wrote:
| Not possible to be in complete sync _and_ have ultra low
| latency. You would have to have a jitter buffer (at least).
| rdtennent wrote:
| My experience with Jamulus might be instructive. Members of our
| group live in the same city (Kingston, Ontario) but use two ISPs.
| Packets between users on the same ISP were fine but packets from
| one ISP to the other were being routed via Toronto and then
| Chicago and ultimately back to Kingston. It's not the distance
| travelled that's the problem (speed of light), it's the latency
| introduced by each intermediate node.
|
| Solved the problem by setting up a Jamulus server on AWS in
| Montreal. Both ISPs provide low-latency connections to Montreal,
| much better than one mile across town!
|
| Of course each participant has to use ethernet rather than WiFi
| and has to use a low-latency audio device, not a laptop sound
| card.
| __turbobrew__ wrote:
| Something similar was happening in Calgary where multiple ISPs
| in Calgary peered through Seattle and Toronto. Luckily YYCIX
| was formed and it appears that things are much better now:
| https://yycix.ca/talks/cuug-2013-06-18/mgp00001.html
| porcc wrote:
| How can you detect these node transfers? I run into similar
| problems often with WebRTC and I have found it troublesome to
| diagnose
| rdtennent wrote:
| traceroute
| weepy wrote:
| The issue with Jamulus is that it requires a central server -
| which means it needs to be close to everywhere . It also needs
| double buffering and double compression. P2P is the way forward
| here IMHO.
| rdtennent wrote:
| "requires a central server" is misleading. You can set up a
| server wherever; there's no _central_ server. Except for the
| multiple-ISP issue I discussed, there 's no reason access to
| a server is more latency than access between the "clients".
| The advantage of the server/client model is that the clients
| can be very lightweight: I personally use a Raspberry Pi 3
| with an ultra-low latency DAC/ADC hat. Works fine. All the
| real computation is done on the server.
| nemetroid wrote:
| Had the same experience in Sweden. Between certain pairs of
| ISPs, all traffic was routed via one of the capital cities
| (Stockholm, Copenhagen, Oslo), adding 10-20 ms and jitter.
| Solved it by setting up a VPS at a provider with good
| connections to all ISPs involved.
| tomxor wrote:
| It's good that latency is considered to be so critical, but for
| the same reason I'm sceptical that this would work well for the
| majority beyond quite local ranges with very good internet
| connections i.e some kind of fiber... which most people don't
| have, although I realise a lot of the tech crowd is unaware of
| this (most of the worlds user end points are some kind of DSL or
| cell network with a 20-40ms minimum).
|
| If anyone has tried playing a processing heavy software synth on
| a pc in real-time you will have experienced how unplayable it is
| as soon as latency goes beyond 10-20ms - you can't play music if
| there is noticeable delay between your fingers and ears, and we
| are much more sensitive to sound latency, it would be the same
| problem trying to play in time with each other.
|
| I like the idea, but feel like the internet isn't there yet for
| the majority of users, and latency hasn't exactly been improving
| at a great pace. I expect it will still be useful in internet
| rich areas like city to city.
| weepy wrote:
| Actually I can jam with ease with my friends in London from
| Denmark. That's over 1000km. And if you don't believe me -
| check the testimonials on https://sub.live ^_^ Also you have a
| much lower tolerance of latency for your own actions that other
| people's. I'm hopefully going to record a video this weekend to
| show everyone!
| digitallyfree wrote:
| Yeah, the hop to the internet exchange point is the main issue
| with DSL or cable. I live in a major city and it takes around
| 10ms to hit the internet exchange point (using Ethernet the LAN
| latency is neglegible) and thus I get a minimum of 20ms or so
| just connecting to a server hosted by someone in the same
| neighborhood. I've actually tried this experiment with some of
| my nearby friends - pinging each other's public IPs on DSL or
| cable takes around 20ms.
|
| With fiber, you can hit the exchange point in 1-2ms. So I
| suppose this tool would work well fine over fiber assuming
| everyone is in the same city. I've even heard of people
| successfully using protocols like Dante (professional audio
| over IP intended for LAN) over gig fiber lines as well.
|
| From my experience, a couple milliseconds of latency is fine
| for keyboard or guitar processing, but anything more than that
| starts to mess me up. There are artists who insist on using a
| full analog chain for monitoring for that reason, and refuse to
| use digital mixers or digital wireless systems that can add
| several ms of latency.
| spenczar5 wrote:
| Why does fiber have lower latency to the exchange than
| copper? That surprises me.
|
| I thought that ISPs generally run fiber for most of the
| distance, and coax is only used for the last few hundred
| meters. The speed of signal propagation is actually faster in
| copper than fiber, but nobody (afaik?) does long runs over
| copper so it's a moot point.
| digitallyfree wrote:
| Yes the ISP runs fiber to the DSLAM or the CMTS, and copper
| is used for the final hop to your home. The latency comes
| from the buffering and processing required to get a clear
| signal over copper - for DSL I think you can get in a
| perfect scenario 7ms or so with fastpath, more if you use
| interleaving. For fiber you can pretty much treat it as
| like an Ethernet connection, with latency determined almost
| solely by distance.
| audray wrote:
| I may be missing something but this appears to me to be a WebRTC
| application. It is very easy to build something like this using
| any modern browser's WebRTC APIs, just disable audio processing
| in the media constraints and munge the opus SDP to stereo, maybe
| play with the network buffer setting if you want to lower latency
| but the audio hardware and physical distance is going matter more
| there.
|
| The developer states that no other software was suitable, and
| also that it's the first of its kind. Both of those statements
| are not accurate: there is nothing innovative in sublive that
| isn't in any of the apps listed below. Props to the developer
| though for scratching an itch.
|
| https://en.wikipedia.org/wiki/Comparison_of_Remote_Music_Per...
| [deleted]
| tytrdev wrote:
| This is super cool. I've been formulating a similar idea for a
| while now. I'm building a desktop utility for guitarists using
| clojurescript and Tauri. I also wonder if this can also capture
| ASIO audio streams in a useful way? My goal was to do something
| like that to allow streaming of processed audio.
|
| Some differences in what I was planning and accompanying
| thoughts:
|
| Clojurescript. I do like that it's using Svelte, I just wanted
| more idiomatic support for datalog stuff for the purpose of
| building metadata-driven music theory tools. Svelte is super cool
| though, and is my go to JS tool right now. There's always
| Datalevin, a portable datalog implementation that I found
| recently. Currently I'm using a locally running XTDB instance for
| development, but for the final shippable I may switch to
| Datalevin. If anyone is interested in doing some similar you
| could try XTDB over http or figure out a nice way to interface
| with Datalevin from other languages.
|
| Electron -> Tauri. Better native feel and the ability to hit Rust
| code directly. May not be worth it for this project since it
| seems like C++ is being used for some stuff. But for me Rust is a
| better fit. As a side note I think the Tauri team is working on
| support for interchangeable back ends, so soon you could replace
| Rust with Go or whatever. Tauri also makes including accompanying
| binaries easy. Not that I'm saying electron doesn't, I have no
| idea.
|
| Capturing ASIO streams. Super important for getting good sound
| for most people, allowing people to play audio through interfaces
| and mixers while still capturing it. I'm not expert in ASIO or
| audio streaming, but from my understanding capturing ASIO streams
| directly is tricky. Reastream (a reaper plugin) is the only thing
| I've found that lets this happen, and sadly it doesn't work well
| with other DAWs. Why this would be useful IMO: people can stream
| audio while still listening to the processed output through
| whatever means they already do. Guitarists could process audio in
| a DAW or plugin and both listen to and stream that audio. People
| using DAWs can stream the output of the DAWs master channel
| without compromising how they listen to it. I'm not saying
| sub.live doesn't accomplish that, I just think it's important
| either way. Typically this is the missing link that makes other
| methods of audio streaming difficult.
|
| Open source. Makes me sad that it isn't. Could have been a good
| building block and I definitely would have tried to be involved
| right away. Feel free to correct me if this is actually open
| source and I just misunderstood.
| jp57 wrote:
| I'm very interested in this! Can you say how this compares to
| something like https://jamkazam.com? One of my issues with JK is
| that it seems to require all participants to be members, and to
| pay for relatively pricy memberships to partcipate. I'm
| sympathetic that nothing is free and I'm willing to pay for a
| good service, but I'd love to have a model where one person could
| pay for a session that others could join (with video) for free.
|
| That said, I'm not sure if you plan to start charging.
| analog31 wrote:
| Thanks for making this. It looks worth giving a try.
|
| Some friends and I get together roughly weekly using Jamulus.
| We're playing mostly jazz standards. We have gotten latency down
| into the 20 ms range, when we are all in the same town. That's
| the ping time. Add another ~ 40 ms that seems to be eaten up by
| my local computer and wired home network.
|
| With that said, online jamming is _hard work_. I 'm the bassist.
| Fortunately I can set my double bass aside and use my electric
| bass, so I'm not hearing my acoustic and delayed sound at once.
| The wind instruments and singer, not so lucky. For the bassist
| it's a constant chore to hold the tempo, leaving little room for
| anything expressive.
|
| I'm glad to be doing this, beats not playing at all, but yet
| there is still no substitute for playing together in person.
| weepy wrote:
| I did actually add a way to play a backing track for some drums
| or similar . It does make it much easier for everyone to stay
| together .
| analog31 wrote:
| That would be nice, a click track. I suppose adding a second
| "user" that generates a click would do the job.
| weepy wrote:
| You could - but you can also just drag in an audio loop
| already.
| wmwmwm wrote:
| I had a look into how Jamulus works under the hood. It's more
| of a hub and spoke model with the central server receiving,
| buffering and resending the stream out to each client. This has
| some advantages (kinder to bandwidth especially as the number
| of clients increases) but it does mean that there are two sets
| of recv buffers (server and client) which need to be deep
| enough to avoid too many missed packets due to jitter. My
| personal experience was that even when running it all on a lan
| I couldn't get much below 16-20ms with an ideal near zero
| latency network. Once you add in geographic latency and
| internet jitter then it goes up considerably.
|
| (Full disclosure: Weepy and I played with Jamulus then he had a
| crack at building sub.live)
| capableweb wrote:
| > Add another ~ 40 ms that seems to be eaten up by my local
| computer and wired home network.
|
| Maybe you have a weak computer? Having 40ms being eaten up by
| your local network would be absolutely bananas, the latency
| should be closer to 1-3ms if not lower. If I ping 8.8.4.4 it's
| not until the switch outside the city I live in that the
| latency comes up to above 10ms, so something sounds
| wrong/broken in your setup if it's really your local LAN having
| 40ms latency.
| weepy wrote:
| If you are on Windows you need to use an ASIO soundcard ?
| capableweb wrote:
| Ah, it's possible analog31 isn't using ASIO card, I assumed
| they are as they seem to have tried to jam before so also
| assumed they were a musician and I haven't met many who
| doesn't use ASIO in the first place.
| analog31 wrote:
| Ah, that's interesting. I'm using a USB audio interface.
| It claims to be ASIO compatible. Oddly enough I tried the
| same interface in different computers, and have tried
| other computers, but haven't dug much further than that.
| I've also tried all of this on a decent Ubuntu box, and
| I've now got it running on a Raspberry Pi 3 since the
| overall latency has been more less the same in all cases.
|
| We're all analog musicians playing alcohol powered
| instruments. ;-) Some of us are techies, others not.
| While I'm a techie, that side of my life has always been
| somewhat separate from the musical side, so I haven't
| paid that much attention to the digital technology until
| the pandemic came along. But I'm happy to learn,
| especially if something simple can make it work better.
| seba_dos1 wrote:
| When the server is in the same town, it's not hard for me to
| get 10-15 ms _total_ latency in Jamulus. 60 ms is a lot -
| borderline unplayable. I get better latency than that over
| WiFi.
| weepy wrote:
| Heya - I recently made a desktop app that lets you jam live with
| your friends over the internet.
|
| You can read more about how it works here => https://sub.live -
| but essentially the latency we achieve means I can jam between UK
| and Denmark with <20ms !
|
| I also added video because it really helps to see the other
| person.
|
| If you're interested - the tech stack is :
|
| * Electron embedding a Svelte app * Websockets to a node server
| to handle the users/room * C++ sub-process that handles the UDP
| networking and audio
|
| BTW It's also free to use for both Windows and Mac.
___________________________________________________________________
(page generated 2021-10-23 23:00 UTC)