[Discuss] suggestions for low latency Internet audio conferencing software suitable for performing music?

[mark at buttery.org (Shirley Márquez Dúlcey)]

Probably the best hope of success here and now for consumers would be for
them to all use the same ISP. I would expect reasonably low latency for
FIOS-FIOS or Comcast-Comcast connections (or RCN-RCN, but there won't be as
many of those), as those will probably never go out to a backbone provider
if they're all in the same metropolitan area. I don't have the actual names
of those servers so I can't do a traceroute test on them.

Alas, that would exclude some people whichever ISP you choose, as there is
no single provider that is available in every city and town in greater
Boston. Once you go between providers, the likelihood of the peering being
done in a more distant location like New York goes up a bunch, and there
goes your latency.

To try out the theory, I just did a couple of Speedtest runs. If I let
Speedtest choose the server automatically it picks either Netblazr or
Starry, and I get a ping time of 4ms. If I manually select a Comcast server
that goes up to 16ms. Still not bad, but noticeably higher. That's actually
worse than the 13ms result I got from selecting Charter's server in NYC.
The most distant server that Speedtest will let me choose is in Reading PA;
36ms.

On Wed, Apr 1, 2020 at 10:12 PM Jack Coats <jack at coats.org> wrote:

> I worked for a little VoIP supplier, one of the worst problems is bad
> latency.  Without ensuring all equipment in your IP path is properly
> configured, ( not possible if using public internet vendors ) the best we
> figured out was to massively over configure dedicated bandwidth. Like 10X.
> Sometimes it did not work.  Some commercial ip provider we had specialized
> in low latency, but it was more expensive than the rest and only did in
> city networking. But this was a long time ago in Houston.
>
> <>< Jack
>
> On Wed, Apr 1, 2020, 8:39 PM Shirley M?rquez D?lcey <mark at buttery.org>
> wrote:
>
>> The first requirement for such a system is a low latency codec that is
>> designed for music. Most commercial teleconferencing systems fail the
>> second criterion; music sounds terrible through them. One possibility is
>> to
>> use uncompressed PCM, which is quick to encode and decode but uses a lot
>> of
>> bandwidth. If we need to keep bandwidth down, Opus is the best open source
>> candidate. https://en.wikipedia.org/wiki/Opus_%28audio_format%29
>>
>> Teleconferencing also requires a low latency video codec. I don't know of
>> any good open source codecs for that. The ones that are used for streaming
>> and for storing movies all have very long encoding delays, in the hundreds
>> of milliseconds or more.
>>
>> Internet latency is also an issue. Some ISPs are much better than others,
>> and there is also the issue that peering between different ISPs sometimes
>> happens at a distant point. Users will want to use wired connections
>> because WiFi adds a significant amount of latency.
>>
>> On Wed, Apr 1, 2020 at 7:34 PM Bill Bogstad <bogstad at pobox.com> wrote:
>>
>> > So lots of people are switching to virtual meetings via video
>> > conferencing for many activities.
>> > Whether proprietary (paid or free sample) or open source, they seem to
>> > assume people taking turns talking to each other.   This model works
>> > very poorly for people trying to play/sing music together due to
>> > latency.   Obviously software can't eliminate the latency caused by
>> > the network itself, but if you are trying to do this in a metropolitan
>> > area among people who normally meet in person, it seems like it might
>> > be possible.  I've done some Google searching for both free and
>> > commercial software to do this and haven't found anything with the
>> > ease of use/low cost that amateurs would want.  Any suggestions?
>> > Depending on hardware/software what kind of latency can you get from
>> > VOIP systems?
>> >
>> > Thanks,
>> > Bill Bogstad
>> > _______________________________________________
>> > Discuss mailing list
>> > Discuss at lists.blu.org
>> > http://lists.blu.org/mailman/listinfo/discuss
>> >
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.blu.org
>> http://lists.blu.org/mailman/listinfo/discuss
>>
>