how to troubleshoot audio glitches

[michael dessen]

Hi all,

First, many thanks to the programmers for this fantastic tool. I've
used it a lot during the past 4 years. Most of the time, I don't have
any problems, but in some situations we get glitches (not sure if they
are "dropouts"?) that sound like this:

http://www.mdessen.com/glitch.m4a

Usually when they happen we also get the "UDP has waited too long"
message.

I am at a university in southern CA. I don't ever get this problem
when connecting to a collaborator at a nearby (60 mi.) research
university. But when we try a three way with northern CA, or when I
try a two-way connection with a collaborator in MA (at Amherst
College), we often get glitches that sound like this. They vary per
site, i.e. sometimes my collaborator hears more or fewer of them than
I do.

I am not sure where to start in troubleshooting this, or what
questions to ask of our network admin people. I could provide details
of our network, software, etc. if needed (we're all on intel Macs,
using the same version of jacktrip and jack router) but I'm not sure
what information to include so please let me know.
Thanks in advance for any help!

Michael Dessen
m...@mdessen.com
http://www.mdessen.com
Assistant Professor of Music
Integrated Composition, Improvisation and Technology area
University of California, Irvine

[Chris Chafe]

Hi Michael,

The tones you included sound to me like dropped packets. You can tune
things up with some command line options.

There are two remedies to try tweaking:
-q (input buffer "cushion")
-r (extra packets to duplicate possible missing packets)

The choice depends on what's killing the packets. If it's jitter, then
move up from -q3 (default) to anywhere, even -q20 and see if that
protects things from jitter "storms." But do it carefully, to find the
lowest queue size that works, since more buffer = more delay.

If the problem is packet loss, rather than jitter, then redundant
packets help. Try -r2, -r3, etc. but beware of "thickening" the
bandwidth (e.g., -r2 takes twice as much as the default). Sometimes
doing that actually provokes a jitter problem you didn't have before.

iperf is a bandwidth tester which can be used to get a sense of the
path

If you want to scale back on bandwidth, stay with 128fpp but reduce
srate to 24kHz, or reduce number of channels.

Hope that helps!
Chris

[IOhannes m zmoelnig]

On 2010-12-14 00:01, Chris Chafe wrote:

> If the problem is packet loss, rather than jitter, then redundant
> packets help. Try -r2, -r3, etc. but beware of "thickening" the
> bandwidth (e.g., -r2 takes twice as much as the default). Sometimes
> doing that actually provokes a jitter problem you didn't have before.
>

since you explicitely recommend using the "-r" flag, i'd like to add
that this never ever worked for me with pre1.1 versions (read: all
versions released); it seems to work with current trunk though.

"not working" means, that i've never been able to connect a client to a
server as soon as the "-r" flag was involved; they just sat there,
waiting forever for the other side.

mfasdr
IOhannes

[IOhannes m zmoelnig]

i have to admit that when i tested it right now, it seemed to work (at
least the connection; no sound-system involed at all)
this has probably to do with the pickiness of jacktrip regarding the
order of arguments.
(which btw, i cannot reproduce now either; however i seem to clearly
remember, that jacktrip didn't like the "-s" or "-c IPADDR" to be NOT at
the beginning (or end, dunno which) of the cmdline args)

fgmart
IOhannes

[Juan-Pablo Caceres]

Hi,

On 12/14/10 5:02 AM, IOhannes m zmoelnig wrote:
> (which btw, i cannot reproduce now either; however i seem to clearly
> remember, that jacktrip didn't like the "-s" or "-c IPADDR" to be NOT at
> the beginning (or end, dunno which) of the cmdline args)

That should have been fixed a loooong time ago (I changed the parsing
long options with getopt_long), and should work in all the releases
through googlecode. That beeing said, if you still can reproduce the
problem please do and we'll try to fix it.

Thanks!
JPC

[Sarah Weaver]

Hi Michael,

A quick endorsement that the -q settings recommended by Chris worked very well in a recent project. I'm sure the -r would as well. Just depends on the factors Chris mentioned.

Good luck with the connection!

Best wishes,

Sarah

 

--
You received this message because you are subscribed to the Google Groups "jacktrip-users" group.
To post to this group, send email to jacktri...@googlegroups.com.
To unsubscribe from this group, send email to jacktrip-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jacktrip-users?hl=en.

[michael dessen]

Thanks everyone! We've tried -r in the past and it sometimes solved
the problem but not always, so I'll experiment with -q also.

2 (hopefully) quick questions -

Will iperf tell me if it's packet loss or jitter?
If I ping the other IP and get a response of "0% packet loss" does
that mean it's jitter, not packet loss?

Thanks so much!

michael

> > jacktrip-user...@googlegroups.com<jacktrip-users%2Bunsubscribe@go oglegroups.com>
> > .

[Chris Chafe]

Hey Michael,

iperf is good at identifying packet loss because it can be set to use
similar packets to jacktrip (UDP) and can ratchet up the bandwidth

typical is:
[server]
iperf -u -s -p4464

[client]
iperf -u -c <server_IP_address> -p4464 -b20M

which would report the results of
a) UDP port actually being open
b) blasting across 20Mbps
then you would reverse the server / client to go the other way (or use
-d for duplex)

Change the amount gradually from 1M anywhere up to say 90M to see where
loss starts to become heavy which is often at some "knee" that tells you
what the path can tolerate. From that you can calculate number of
channels, their audio resolution, redundancy level, etc.

1 ch x 48000 x 16bit is approx. 1Mbps (and -r2 is twice that, for ex.)

iperf also reports jitter but it isn't using a similarly-timed packet
stream and therefore doesn't really relate. I recommend finding the
bandwidth capacity for loss, staying under that with your stream and
then if there's still drop outs increase -q -- if that fixes things then
it's jitter.

Phew, there are better ways on the drawing board but this is what we've
arrived at in practice. Ping isn't really useful for fine tuning
jitter / loss but does give a decent rough estimate of what you'll
experience in a round trip delay.

Chris

[Synthia]

@Sarah: were you tweaking during the show? We had similar sounds
during the 3-way b/t CU-NYU-IUPUI. I'm always afraid tweaking the
stream will cause disconnection during the show. It's fun for me,
but...

thanks to Michael for firing this up.

synthia

On Dec 14, 8:45 am, Sarah Weaver <sarahrwea...@gmail.com> wrote:
> Hi Michael,
>
> A quick endorsement that the -q settings recommended by Chris worked very
> well in a recent project. I'm sure the -r would as well. Just depends on the
> factors Chris mentioned.
>
> Good luck with the connection!
> Best wishes,
> Sarah
>
> On Tue, Dec 14, 2010 at 6:45 AM, Juan-Pablo Caceres <
>

> jcace...@ccrma.stanford.edu> wrote:
> > Hi,
>
> > On 12/14/10 5:02 AM, IOhannes m zmoelnig wrote:
>
> >> (which btw, i cannot reproduce now either; however i seem to clearly
> >> remember, that jacktrip didn't like the "-s" or "-c IPADDR" to be NOT at
> >> the beginning (or end, dunno which) of the cmdline args)
>
> > That should have been fixed a loooong time ago (I changed the parsing long
> > options with getopt_long), and should work in all the releases through
> > googlecode. That beeing said, if you still can reproduce the problem please
> > do and we'll try to fix it.
>
> > Thanks!
> > JPC
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "jacktrip-users" group.
> > To post to this group, send email to jacktri...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > jacktrip-user...@googlegroups.com<jacktrip-users%2Bunsu...@googlegroups.com>
> > .

[Sarah Weaver]

Hi Synthia,

Nice to hear from you, hope all is well!

From what I understand, these are settings you can only make when establishing the connection. I have not heard it's possible to tweak with these settings during the connection, though that would be a nice feature one day. For now, you would have to disconnect to apply the settings, so it's something to tweak when you first make the connection.

We used -q for the ResoNations 2010 project: http://resonations.kaist.ac.kr/

UN/Beijing/Seoul with Calgary bridge. The internet connection at the UN has the bandwidth and static IP but it's not a clean line. We had to reduce the number of channels and use the -q settings recommended by Chris. It worked great, was absolutely the solution.

For the project Inspiraling: Telematic Jazz Explorations: http://www.roulette.org/events/event.php/INSPIRALING2010

We connected NYU-UCSD 8 channels, this worked without any further settings.

I'm sure we've all experienced varying degrees of clean internet connections. These -q and -r settings are great tools for noisy lines. 

Best wishes,

Sarah

On Thu, Dec 16, 2010 at 10:58 PM, Synthia <synthi...@gmail.com> wrote:

@Sarah: were you tweaking during the show? We had similar sounds
during the 3-way b/t CU-NYU-IUPUI. I'm always afraid tweaking the
stream will cause disconnection during the show. It's fun for me,
but...

thanks to Michael for firing this up.

synthia

On Tue, 2010-12-14 at 11:05 -0800, michael dessen wrote:
> Thanks everyone! We've tried -r in the past and it sometimes solved
> the problem but not always, so I'll experiment with -q also.
>
> 2 (hopefully) quick questions  -
>
> Will iperf tell me if it's packet loss or jitter?
> If I ping the other IP and get a response of "0% packet loss" does
> that mean it's jitter, not packet loss?
>
> Thanks so much!
>

> michael 

To unsubscribe from this group, send email to jacktrip-user...@googlegroups.com.