[HN Gopher] Jamulus - Play music online. With friends. For free
___________________________________________________________________
Jamulus - Play music online. With friends. For free
Author : thunderbong
Score : 139 points
Date : 2021-11-25 05:24 UTC (17 hours ago)
(HTM) web link (jamulus.io)
(TXT) w3m dump (jamulus.io)
| axismundi wrote:
| By following the setup guide I was able to achieve 30-60ms
| latency. It's still a lot of fun. I spent a lot of time playing
| with others during the pandemic. A few tips for better
| experience: - Mute participants that have high delay. - Avoid
| rooms with more than ~10 participants. - Mute yourself if you are
| not playing. - Adjust your volume properly. If you are too loud,
| others may hear clicks and may perceive it as audio drops.
| ohadron wrote:
| So now that the tech exists, where is the service that helps
| matching different people who want to jam?
| dtinth wrote:
| In the past 4 months, I got to know over 30 people by jamming
| with them on Jamulus. When you click on the "Connect" button
| Jamulus will list the public servers, sorted by latency. It
| will also list the name of people in each server. This works
| pretty well if there are Jamulus users in your area.
|
| 8 months ago, before Jamulus became more popular in my area, we
| used Clubhouse to connect with more musicians. We started a
| Clubhouse room and streamed the sound from Jamulus to that
| room. We put the server IP address in the room title and in the
| bio so listeners can connect to our server and jam with us.
| This brought our group from 3 people to about 20 people.
| drewm1980 wrote:
| Light is not fast enough to do this for real... Do they have a
| new UI trick that is good enough to be fun?
| rdtennent wrote:
| The magical belief that p2p is always superior to server-client
| for this kind of application has to be refuted. I live in
| Kingston Ontario, a medium-sized city between Montreal and
| Toronto. There are essentially two high-speed ISPs: Bell, using
| fiber, and Cogeco, using cable. Latency between peers on the
| _same_ network is usable, but packets from one network to the
| other, even a few blocks apart, are routed via, for example,
| Toronto to Chicago to New York to Montreal and finally back to
| Kingston. It 's not the distance travelled that was
| problematical; it's the latency introduced at each intermediate
| node. By setting up a server at AWS in Montreal, the latency for
| peers on both networks became usable.
|
| Also, p2p requires O(n^2) links whereas client-server has O(n)
| links, so if the number of peers increases, the total travel time
| difference will be more significant.
| sealeck wrote:
| Doesn't that assume that you have a total mesh topology (rather
| than e.g. a ring) for p2p?
|
| I assume that it's not time-prohibitive either for each device
| not to be directly corrected to each other device.
| rdtennent wrote:
| No matter what topology is used, the basic issue is the same:
| if _any_ of the p2p links introduces unacceptable latency
| (such as the inter-ISP link I described), the whole system is
| borked. The clients are generally not movable (or would need
| to switch to another ISP) but a Jamulus server _anywhere_ can
| be used or set up and may provide acceptable latency for all.
| mrmrcoleman wrote:
| I read somewhere that musicians can only tolerate up to ~20ms
| latency to be able to perform together "live".
|
| The speed of light gives you ~186 miles per millisecond, which
| assuming you need to make a round trip in 20ms gives you an upper
| distance of ~1900 miles for live performance.
|
| In reality however this will be _much_ lower due to processing
| overhead, speed of light in fiber (~0.7e), and internet backbone
| topology.
|
| Curious to know if the creators have done any tests, (or can show
| any demos) of the effective range this works at?
| graynk wrote:
| There's a whitepaper on the website. Short answer: they don't
| care
|
| > There are a lot of people arguing that online jamming does
| not work because the overall delay is too high. They claim that
| latencies above 10 ms are not acceptable. In Jamulus typical
| overall delays are in the range of 30 to 70 ms. It is also
| typical that audio dropouts occur frequently (usually every 2
| to 10 seconds per audible pop/interrupt sound). It has been our
| experience that, if the audio dropouts are not occurring too
| often, they are not perceived if the band members concentrate
| on their playing. If one focuses on the dropouts (and this is
| what people usually do when they try out the software) it feels
| annoying.
| iainctduncan wrote:
| It's... complicated. What musicians can tolerate with practice
| and what will throw them off at first and muck them up is quite
| different. And there's the question of what you're playing - I
| can play slow stuff with terrible latency and it's fine, but
| start to play quick and you really feel it. It also depends on
| the instrument, it's a lot weirder playing something where the
| haptic feedback is off from what you expect on that instrument
| (or missing).
|
| But in general, 20ms is considered the top end of fine. A good
| player can totally feel the difference between 10 and 20
| though. Under 10 is not really an issue. After that, you have
| some stuff to get used to and while you might be able to jam,
| it's affecting you.
| caslon wrote:
| Latency is a lot lower than people generally think it is. I'm
| currently on a terrible satellite connection (not the popular
| one), and the latency to ping 1.1.1.1 averages 16.184ms right
| now, during awful weather, and never hits above 25ms. Probably
| the _worst_ modern case scenario you could imagine for latency
| 's sake, and significantly worse than I had ten years ago. In
| better weather, it's half that.
|
| If you pull a few tricks, it wouldn't be anywhere near
| impossible to manage sub-20ms latency on your average
| connection. Now, over a web browser? I couldn't tell you. I
| wouldn't bet on it. But definitely possible natively.
| cbg0 wrote:
| > I'm currently on a terrible satellite connection (not the
| popular one), and the latency to ping 1.1.1.1 averages
| 16.184ms right now, during awful weather, and never hits
| above 25ms.
|
| 1.1.1.1 is anycasted to many points of presence, one of which
| might be in the same state as you, so this data point is
| somewhat irrelevant. I'd be more interested in seeing what
| king of latency & packet loss you experience to another
| residential connection far from your location.
| caslon wrote:
| Your objection is taking my comment in the least-
| intelligent light. There's no _reason_ for this service to
| be P2P; MITMing the connection with a selective forwarding
| unit would work fine and is the natural conclusion one
| should reach when analyzing this problem. Cloudflare-in-
| the-middle would work perfectly.
|
| Like any modern video game, or half of the decent video
| chat options in the world.
| KennyBlanken wrote:
| And people don't realize how "high" latency is for sound in
| air. 3ms per meter. Sound is 400,000 times slower per
| distance. Someone 10 feet away in your living room has the
| same latency as someone about 750 miles from you via magic
| network pixies (ignoring routing/switching delays, and the
| latency of each computer at either end going from bits into
| the network card, to electrical signal changes out the sound
| jack.)
|
| In your case, 25ms network latency is equivalent to being 8
| meters from another musician. That's basically "the other
| side of a medium-ish room."
|
| It is funny seeing HNers so incredulous that something like
| this would work, when apparently lots of musicians have been
| using stuff like this for over a year, without issue. I wish
| more HNers realized that being smart isn't about knowing
| things. _It 's about knowing what you know_, and
| understanding things like biases.
|
| "Well, my knee-jerk reaction is that latency would be a
| problem. But I'm not a musician and I have no experience
| here. And clearly a bunch of people put a fair amount of
| effort into this. Let me see if my knee-jerk reaction is
| correct by either waiting to seeing what people who have
| actually used it say, or doing out the math to compare
| typical network latency to sound-in-air delay."
|
| That's what a smart person says to themselves.
|
| A smart person does not say, "This couldn't possibly be
| practical, I'm going to comment immediately to that effect."
| Aeolun wrote:
| I think we have enough smart people that are also musicians
| on here.
| ggm wrote:
| Tried it UK AU. Some latency cannot be fixed. It's 200ms class
| delay. Light speed gotta rise.
| modeless wrote:
| Starlink could do significantly better in theory once the
| constellation of satellites with laser links is operational.
| The speed of light in vacuum is much higher than in optical
| fiber. If the data can be routed in space and travel directly
| from source to destination terminal instead of bouncing to and
| from ground stations then under 100 ms should be achievable.
| The light speed limit would be 50 ms (assuming that the data
| can't cut through the Earth's core).
|
| It's unknown if Starlink will routinely route packets directly
| between user terminals or if that will be a special service
| sold only to customers willing to pay a premium. We'll see when
| the constellation is ready.
| Y_Y wrote:
| The increase in travel time comes from: extra path length
| from bouncing between the sides of the inner fibre (depends,
| maybe 20%?) and from refractive index slowdown (about 70%).
| But then you have to worry about the greater total path from
| going into space, and also mux/demux/boosting delays.
| nathannecro wrote:
| For those who didn't take the bit of time to read the case study
| linked on the homepage of the OP, it answers the obvious question
| of "well isn't latency a problem?". It's well written and lays
| out some neat ideas.
|
| For those who are too lazy -- TL;DR:
|
| The software allows players to set up servers easily so if a band
| is geographically close, but remotely dialing in, latency is
| reduced. The software is intended to be used as the primary
| method of sound feedback so it's advised that amps are turned off
| and earplugs/headphones are used to block out "local" sound. And
| finally, the author of the case study found that their experience
| with latency was between 30-70ms and that was more than
| acceptable. The only problem stemming from this latency was that
| songs with fast drum fills needed some adjustments to slow down
| the drum fills.
| MikusR wrote:
| There is also an old project by one of the Winamp creators
| https://www.cockos.com/ninjam/
| fabrixxm wrote:
| That's a little different. While Jamulus tries it's best to do
| realtime audio, ninjam works deferred. Players agrees on a bpm
| and a number of bars, the software will record each bar and
| send to other that will cache them and then play them on the
| next loop.. so every player will hear others one phrase late.
| (sorry for non precise terminology...)
| tapland wrote:
| So far in the comments only worries about latency.
|
| I had the same worries when my father told me about Jamulous and
| that his band started using it during the pandemic. They are a
| cajun band and mostly jam and they were singing the softwares
| praises and have used it for all practice leading up to the real
| life perfomances they've had the last few weekends.
|
| It seems it's not actually a big issue, at least over a distance
| of about 300 miles.
| alexbuckland wrote:
| You get the best experience of jamulus usijg a server that is
| optimised for that purpose in a location that is equidistant for
| all members. Best service there is for this is
| https://melomax.live
| FrostKiwi wrote:
| I maintain couple of digital music teaching rooms. (instruments
| connected via audio interfaces, teachers switch cameras via
| elgato minis, etc.) We also setup Jamulus with a couple of
| students, by sending out 100$ equipment packages. In Germany and
| it's mix of VDSL2 in the cities, ADSL on in the countryside and
| fiber for a couple lucky regions, Jamulus is a very mixed bag. If
| it works, it's magic, but the reality of infrastructure makes a
| recommendation hard, if you do not have an IT guy on staff.
|
| Here is what we came up with: Whilst professionals can deal with
| the delay (playing notes in the future) that comes from Jamulus
| with a suboptimal connection, Students can not. We misuse
| Jamulus' concept to create a workaround. We walk students through
| port-forwarding and students start the jamulus server via a
| script, that connects to our private jamulus directory server.
| Then the teacher connects to the students machine. As a result,
| the student gets 0 delay and the teacher, with his experience has
| to carry deal with the delay and has to compensate for it. Huge
| pain to setup, but the quality of the lesson on the student's
| side does not suffer, even if the connection is bad.
|
| On a funny side note, IRL I witnessed the exact opposite problem.
| A piano soloist professional was playing the Weichnachts
| Oratorium with the Kreuzchor choir I sang in. The soloist had to
| play the Harpsichord, which responds instantly (strings plucked
| under tension), as opposed to the Piano's hammmers, which have a
| "slight delay". The professional was so used to this "small
| delay", that he had to relearn and adjust a lot, because his
| professional experience with the piano produced too early timings
| with the conductor's actions. So the opposite of what teachers
| face with Jamulus.
| iainctduncan wrote:
| And then there are pipe organs. Man, I don't how they do it,
| the latency is so big! Didn't know that about harpsichord
| though, that's interesting.
| Cthulhu_ wrote:
| I like that little anecdote.
|
| I think when learning to e.g. play drums like I once did,
| another realization is that you need to start the motions well
| before the impact. Actually, this is what a lot of people that
| start warbling among with songs badly fail at - they try and
| follow along, but they need to start singing (or tapping)
| before the song they play along with does, which means they
| need to know the lyrics and what comes next already.
| dtinth wrote:
| While there is definitely some latency, we've found it to be
| bearable. Last week we just performed a jam session of 10 people
| live on the PyCon APAC online conference using Jamulus, and
| here's the video clip:
| https://www.youtube.com/watch?v=rvb_n1fwH4E and one more
| https://www.youtube.com/watch?v=inGQdo1nrt0
|
| Most new people who try out Jamulus and join our servers would
| complain about the latency (especially professional musicians),
| to which I give the same advice: 1) Use a fiber-optic internet
| service. 2) Use a LAN cable. 3) Use wired headphone (no
| bluetooth/wireless headphone/AirPods). 4) Use an audio interface
| with ASIO device or use a Mac. Finally, and most important: 5)
| Just play 100 songs on Jamulus, and you'll eventually get used to
| it.
|
| Most friends are jamming with latency of around 20ms. I have
| found that for vocals and drums, maximum latency tolerance is
| around 30ms. For me I play the keyboard and most of the time I'm
| jamming over a 4G mobile network, I have increased my latency
| tolerance to about 100ms now.
| tkgally wrote:
| Hey! Those video clips sound great. I especially liked the
| first one. It's really encouraging to see that people can make
| music together remotely.
| melcon wrote:
| You should check Jamulus WorldJam channel:
| https://www.youtube.com/c/WorldJam
|
| Next event scheduled for Dec 4th 17:00 GMT
| MaxikCZ wrote:
| Its baffling to think that the latency between computer and
| headphones might add multiples of latency added to the signal
| going hundreds of miles from one computer to another..
| lillesvin wrote:
| If you're sitting 5 meters from your speakers, you add about
| 15 ms of latency and, in some cases, people all the way
| across the globe will hear your sound before you hear it
| yourself.
|
| It's pretty wild to think about. My dad used to point out to
| me that, if I was watching a live concert on the TV, the
| sound would reach me before it reached much of the live
| audience.
| ZoomZoomZoom wrote:
| > in some cases, people all the way across the globe will
| hear your sound before you hear it yourself.
|
| You're vastly exaggerating. FTL communication is not here
| yet.
|
| The theoretical limit for half the planet is ~67ms, in
| practice it's north of 100ms for Jamulus (plus the
| additional delay of a user's sound reproduction system).
| MaanuAir wrote:
| FTS, not FTL.
|
| I believe the example above is more about sound speed
| than light speed.
|
| I experienced concerts in stadiums, in the back rows,
| where the distance from the stage makes the sounds arrive
| noticeably later than the visuals.
|
| The delay is really perceptible, and disturbing, to a
| point.
|
| A TV audience would not suffer from it (assuming a live
| broadcast, with negligible broadcast latency, for the
| example to make sense).
| dtinth wrote:
| This.
|
| I found that most of the latency in networked audio
| applications, when jamming within 800 km within domestic
| internet, mostly comes from (a) a large network buffer (to
| prevent sound stutter when the network isn't reliable, e.g.
| due to wi-fi interference) and (b) extra audio processing
| on top (echo cancellation, noise suppression), and not the
| limitation of light speed.
| genewitch wrote:
| USB soundcards were so featureful compared to onboard or even
| the pci stuff when they came out, like the sound blaster
| extigy. I liked positional audio and all of the spdif and
| toslinks. However, it, by itself, even with ASIO had latency
| up around 30-50ms.
|
| I have an external "headphone out and 2 microphone in" USB
| interface now, and it's latency is still in the 5-15ms range,
| so I use onboard to write and headphones to master. At one
| point I bought a macbook air and a FireWire interface, but
| the screen was no good and the single FireWire interface tied
| my hands. I also have a few pci cards that I've been
| collecting parts for, like an m-audio 8x8 interface, there's
| a box that connects to the back of the soundcard with some
| 30-40 pin d-sub. I finally got all 5 or 6 parts and don't
| really have a computer to put it in anymore! I wanted that
| card for around 10 years by the time I found all of it...
|
| I'm assuming anything midi-ish can just use quantization and
| only the player will notice, the final mix should sound ok.
| KennyBlanken wrote:
| In case it wasn't clear, parent commenter probably means
| "don't use bluetooth headphones." There's no latency for
| wired headphones.
|
| Apt-X "low latency" is 33ms - the equivalent of being about
| 11m away from the sound source.
|
| Standard Apt-X is 100ms, or equivalent to 33m distance in
| open air.
|
| SBC codec is 200ms.
|
| Then there's the buffering headphone bluetooth chipsets may
| do to avoid customers complaining about clicking/popping. If
| you're on a crowded subway train there can be a shitload of
| bluetooth traffic bouncing around, in which case having a
| healthy buffer is helpful.
| seba_dos1 wrote:
| > 4) Use an audio interface with ASIO device or use a Mac.
|
| ...or GNU/Linux, where Jamulus on JACK works wonderfully with
| low latency and easy audio routing across apps.
| bckr wrote:
| Your jams are beautiful! Thanks for sharing! I can't believe
| this is actually possible at this quality.
| oever wrote:
| > I have increased my latency tolerance to about 100ms now.
|
| Every musical instrumented (voice too) has a latency. The
| practiced musician is trained on the latency of themselves and
| their instrument and will initiate a musical note at the right
| time. That might even be a few seconds in advance.
|
| Part of learning an instrument is learning its latency. Jamulus
| adds a bit on top of that. That requires some getting used to.
| A good tip is to listen to your sound over the internet. So
| wear insulating headphones that keep out your real-time sound.
| jerrre wrote:
| I'd say that listening to your own instrument with latency
| does not work at all. Making good tone/timbre/pitch etc all
| depend on a very short feedback loop between
| hands/ears/brain.
|
| edit: replace hands with whatever is needed to produce the
| sound: vocal chords, mouth, feet, arm, ...
| seba_dos1 wrote:
| Listening to your own instrument with latency is what makes
| it actually work and is essential for online jamming.
| mrmrcoleman wrote:
| Those videos are great! Where were you all located, physically?
| I'm trying to get some sense for the geographical limits of
| this sort of thing.
| dtinth wrote:
| Thailand. Ping time using fiber obtic internet is 4
| milliseconds.
|
| Playing from Thailand in a Singapore server, add 27
| milliseconds.
|
| Playing from Thailand in a Hong Kong server, add 65
| milliseconds.
| mrmrcoleman wrote:
| Thanks!
| DerWOK wrote:
| Other FOSS product that tries to solve the same problem and which
| worked a little better for us. (We tried both)
|
| https://www.sonobus.net/
| KennyBlanken wrote:
| Wow. It's clearly a more mature, featureful project. The UI
| looks amazing, too.
|
| Maybe the Jamulus folks can combine forces with Sonobus folks,
| implementing any Jamulus features Sonobus lacks.
| ZoomZoomZoom wrote:
| It's exactly the opposite. Jamulus is far more mature, first
| release is from 2006.
|
| The Sonobus UI is nice and responsive, coming from JUCE, but
| it's not native. More features, like metronome, are nice to
| have, but most musicians won't use them anyway as the
| instruments are usually connected through DAWs which provide
| all the necessary instruments for routing and layering
| sources.
|
| The main difference is in the architecture, Sonobus is p2p,
| so it's great users have the option to try different
| approaches and find what works best for them.
| morsch wrote:
| I know people who regularly used this for rehearsals during the
| pandemic (maybe they still do). I told them about it when it was
| previously featured here. They were thrilled. These were people
| that used to meet locally, so presumably the latency was
| relatively good.
|
| Another group was interested, but the setup was too complicated
| for them (wired ethernet, messing around with asio). But if you
| can get beyond that, it's apparently pretty great. There might be
| a product idea there, a plug and play solution that avoids the
| manual setup.
| rdtennent wrote:
| Jamulus software is not only free (gratis and libre) but its use
| is completely anonymous: you may have to open a port but you
| don't have to open your inbox to spam or register in any way. And
| users don't need to authenticate to use a server, either "public"
| (i.e., advertised automatically in connection windows) or private
| (i.e., using an IP address known only to musical peers). There's
| no encryption but if you use a private server there's virtually
| no possibility of anyone other than designated peers to listen
| in.
| foolinaround wrote:
| i was thinking that maybe a different approach with regard to
| latency could be tried... after all, these are not trades that
| need to reach a central server.
|
| Rather than reduce latency, why not increase latency so that for
| the participant with the worst bandwidth, it can be delayed 1
| sec, for the one with the best, it is delayed so that it syncs
| with the other person.
|
| For a period of time when all participants have clicked that they
| are ready, real time is suspended, and some kind of calculation
| is made that will the voices in sync.
| jefftk wrote:
| I think maybe https://echo.jefftk.com is what you're looking
| for? Also open source.
| analog31 wrote:
| I'm a so called semi-pro jazz bassist. During the pandemic, some
| friends invited me to join an online jam using Jamulus. So I
| learned some things.
|
| I don't think that "latency" boils down to a single dimension,
| because there are multiple competing latencies when you play
| music. It's a complicated feedback loop with multiple input and
| output channels.
|
| I think how well it works depends on being able to isolate the
| acoustic sound of your instrument from what's coming through your
| headphones. Your brain will prioritize whatever comes first, so
| if you can hear your own acoustic sound against the delayed sound
| of the band, you will instinctively slow down, and a band allowed
| to do this will grind to a halt. [0]
|
| Electric instruments are easy, because they have little or no
| acoustic sound. I found it much easier to play solid body
| electric bass than double bass, though double bass is my main
| instrument. My hands adapted to the latency, as they do anyway
| because each instrument has inherent latency.
|
| Winds and voice are difficult, because you hear yourself through
| bone conduction. Drums are hard to isolate with headphones. But
| people tend to (mistakenly) get the time from the drummer.
|
| It fell to the electric instruments to "drive" the band. That was
| _profoundly fatiguing_. When I tried to take a solo, the band
| would get lost. And my solos can be blatantly rhythmic if I need
| them to be.
|
| This is compounded by the fact that a lot of musicians are not
| techies, so the explanations about how they have to play
| differently, and work with the technology, goes over their heads.
|
| [0] Imagine playing at 120 beats per minute, which is 500 ms per
| beat, with 30 ms latency. That's like 6% per beat. So while
| everybody says that 30 ms is pretty good, that much latency with
| the feedback loop described above will cause the band to lose
| tempo by 6% per beat. And 120 is a relatively stately tempo if
| you like "hot" jazz.
| dtinth wrote:
| This reminds me of what happened on the first few weeks of
| trying out Jamulus. Every musician tries to match the tempo of
| other musicians. This results in the song gradually slowing
| down as you described. The next thing we realize is that we are
| playing songs at 50% speed.
|
| So in the end we designated some instruments to drive the song.
| Usually its the drums. The person who drives the song must not
| wait for other instruments and keep their own tempo, and
| everyone else try to time their instruments to be in-sync with
| the drums. It works quite well for us.
| wishinghand wrote:
| > But people tend to (mistakenly) get the time from the
| drummer.
|
| I guess I'm a musician that makes this mistake. Where does it
| come from?
| winnit wrote:
| I think he means that in this case it's a mistake as it would
| be wisest to take the tempo from the electronic instruments.
| analog31 wrote:
| Traditionally in jazz, the bassist provides the pulse, and
| the drummer provides color. This isn't true in all genres.
| And in a bigger band, the rhythm section (piano, bass, drums,
| guitar) has to function as a cohesive unit.
|
| Although, optimally, the tempo just seems to sustain itself,
| a condition that's only met by the best players. Playing bass
| alongside a drummer with great time is certainly a better
| experience, and there are drummers with better time than me.
| Time is one of those things that's a lifelong pursuit, not
| something that is ever "good enough." Likewise intonation.
|
| Using Jamulus, it seems to work best when the tempo is driven
| by instruments that can be isolated from the feed coming from
| the headphones, so for instance electric bass works better
| than double bass, though they both function as "bass."
| everyone wrote:
| There's no way latency over the internet would be low enough to
| jam together... The latency of normal _local_ computer soundcards
| without ASIO is too high for jamming. Anything above 10ms is
| noticeable.
| rhizome wrote:
| People have been trying this for over 20 years, the first one I
| knew about was a Dutch company piping (IIRC) MIDI across the
| globe with a Shoutcast-style client app. "DragonNet" or
| something.
| DerWOK wrote:
| Not true. It works. After some brain adaption. Then it's fun.
| And what is jamming about? Fun! Not recording the next chart
| breaker.
___________________________________________________________________
(page generated 2021-11-25 23:02 UTC)