Jacktrip dropouts worse than Jamulus - better options?

[neal rhodes]

So, 1.3.0 server on Ubuntu linux on 200/24 Comcast.  24-34ms ping times to VS boxes.

jacktrip -S -V -n 20 -a 10 -p2

Jamulus -s -n -l jam.log -T -u 8

Jamulus quality is useable; Jacktrip is ... not.  Enough dropouts that we're using Jamulus instead.

Are there options to improve this?  -q?  Suggested values?  Is there something we'd need to do on the VS side to match?  "Queue" is set to auto on the VS side.

regards,

Neal

[Bonnie Kwong]

Are you measuring dropouts quantitatively or listening?  

I always add the -z param to zero out dropped packets instead of repeating the last one, which causes a buzz.  Another possible difference is Jamulus uses compression.  As far as I know, there are no definite plans to add compression to JackTrip, though the subject comes up from time to time.

Bonnie

--
You received this message because you are subscribed to the Google Groups "jacktrip-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jacktrip-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/fdc78863-007f-4dfe-8e95-a72f423e236bn%40googlegroups.com.

[neal rhodes]

Thanks for the reply.  I am just listening, and concluding there is no way I am using this in a church service, due to the dropouts.   I can try -z, although I thought that was just going to cause a different kind of disturbance.

So, given the server, AND the VS client which feeds the sanctuary mixer is on a 200mbit Comcast connection,  I don't see it getting any better in Atlanta.   (FYI, local MTA servers are 29ms away)    I would think our situation is going to be pretty much best-case typical for groups outside the fiber area of most cities.

Note that for us, the VS client that really really really matters is 3ms away from the server downstairs.   If we tweaked things so that was clean, and all the other clients had some noise, well, we could live with that.

So, do we have a general strategy on what we tweak for dropouts?   Fortunately I can ping most all the clients from church.  It would seem better to follow a strategy rather than just start messing about with multiple parameters.  

What about the bufstrategy?  Do we know when to use that?

Regards,

Neal

[Bonnie Kwong]

I would try -z and --bufstrategy 1.  Chris Chafe has been doing some work analyzing buffer strategies.  It would be great to look at his findings when they're ready.

Here are some notes from Anton Runov, the developer of the jitter buffer:

To enable the new JB you have to add '--bufstrategy N' option to the

command line. For now there are 3 strategies available

0 - mostly similar to the old behavior.

1 - an optimized version reducing latency jumps, it is recommended in

most cases.

2 - a special strategy for stable latency; it is optimized for longer

queues and requires at least -q3.

First of all, a buffer strategy is an algorithm that decides whether a received audio packet should be sent into the playback port, delayed (by inserting some extra samples before it) or dropped. You need to insert or drop some samples to keep the latency limited.

Strategy 1 will drop as little of received audio data as possible without exceeding the maximum queue length. This is the most obvious goal and it is the default. It behaves very similar to the original ring buffer implementation but implements a few fixes to drop even less audio. Namely, it drops only one buffer at overflows (the RB drops a half of the queue length in this case). It does not drop the most recent packet at overflows (the RB does). It also behave slightly differently at deep underruns (when more than 1 packet was missed) by increasing latency more conservatively than the RB does.

Strategy 2 is optimized to keep the latency stable. That means keeping it close to the maximum queue length all the time (this is the only way you can keep the latency stable). While in the strategy 1 the actual latency can vary (and fluctuate) between 1 buffer and the max queue length, the strategy 2 will always try to keep it at the maximum. Thus, it usually produces higher latency than the strategy 1 (well, if a queue length is selected properly the difference is negligible). It also drops slightly more audio (in most cases the difference in drops is also quite small). All these downsides are the cost of having latency stable (or minimizing the discontinuities in the output audio stream which is pretty much the same). To me, the most interesting question is if it worth it. Is stable latency important enough for making music to accept a bit worse audio quality? I guess the answer might depend strongly on particular parameters of network connection and buffer size, but also on the type of music being played and probably on musicians preferences.

One more note about strategy 2 is that to operate as designed it requires some wiggle room in terms of the queue length. So basically you need -q4 or more. In the previous version it tended to behave poorly at short queues. It dropped much more audio than required etc. In the current implementation it is transitioning towards strategy 1 in such cases. Instead of dropping too much audio when the queue length is insufficient it will just accept latency jumps and behave like a ring buffer. Thus, now specifying -q2 /-q3 is safe but the latency might not be as stable as with higher q values.

Bonnie

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/1c94388a-8630-41a7-b7a2-bb22670f4f35n%40googlegroups.com.

[neal rhodes]

So, this implies leave -q alone at default of 4?   It helps to have FEWER parameters to juggle/test if we expect them to have no difference.   I recall seeing some email at someone trying -q20.

regards,

Neal

[Bonnie Kwong]

Leave -q at 4 initially, but increase it if you want to improve audio quality, up to 64.  You can tweak the -q values on both the client side and the server side.  I've found that they do make a noticeable difference.

Bonnie

To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/ca8d8a88-d764-4e3b-ad30-23fc9f68d09cn%40googlegroups.com.

[Bonnie Kwong]

Oh...there's a general tradeoff between audio quality and latency.  If you run JACK at 32 frames per period, you'll get excellent latency, but audio quality may be compromised, and vice versa at 1024, so that's another setting you can tweak.

Bonnie

[Fernando Lopez-Lezcano]

On 2/15/21 10:38 AM, neal rhodes wrote:
> Thanks for the reply.  I am just listening, and concluding there is no
> way I am using this in a church service, due to the dropouts.   I can
> try -z, although I thought that was just going to cause a different kind
> of disturbance.
>
> So, given the server, AND the VS client which feeds the sanctuary mixer
> is on a 200mbit Comcast connection,  I don't see it getting any better
> in Atlanta.

My experience with Concast here - San Carlos, CA - has been that the
number of Mb/s of the service was irrelevant. I was trying to use only
10% of the "potential" bandwidth and getting really bad dropouts. What
was relevant was the packet loss, or jitter which lead to packet loss,
which made the connection unusable. That is not something they talk about.

Sometimes the connection would be good, sometimes completely unusable.
What I called "internet weather".

Actually everything was fine for the first 10 to 15 seconds of a new
connection and then performance degraded really fast (they boost the
performance for a little bit to appear to be good - but keep in mind
that I was ALWAYS trying to use just 10% of my supposedly good speed,
which means they delivered packets in time for the first 10 or 15
seconds and then they said, well, "whatever").

I was lucky that I could actually get a DSL connection - in addition to
Concast, for several reasons - and that was rock solid. The bandwidth
was actually only 24M down and 2M up which was barely enough for stereo
with no other activity on that ISP connection, but I could make music. YMMV.

I also tried jamulus at the time and it was better (on Concast). As it
is compressed it uses less bandwidth and the traffic shaping that
Concast does had less influence (or was just below their radar). But it
was far from perfect. Packet loss would translate into a weird warbling
distortion of the sound (typical decompression artifacts). So, better,
but overall much worse sound quality under the conditions in which I was
testing.

For jacktrip/concast changing the jack buffer size seemed to help. 1024
seemed to be best but of course that was a huge latency. As Bonnie said,
"-q" will help, but at the cost of more latency.

-- Fernando

> <https://groups.google.com/d/msgid/jacktrip-users/fdc78863-007f-4dfe-8e95-a72f423e236bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "jacktrip-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jacktrip-user...@googlegroups.com

> <mailto:jacktrip-user...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jacktrip-users/1c94388a-8630-41a7-b7a2-bb22670f4f35n%40googlegroups.com
> <https://groups.google.com/d/msgid/jacktrip-users/1c94388a-8630-41a7-b7a2-bb22670f4f35n%40googlegroups.com?utm_medium=email&utm_source=footer>.