Garbled inbound audio on one node on a multi-node host

1

Greetings:

So, here’s a weird one that I can’t figure out, and I’m not even sure where to start debugging.

A friend is running the latest ASL3 from the stable repository on a Dell Zeon workstation. He has two public nodes on the box, each with a separate simpleusb channel. One node (592140) is connected to a SHARI. The other node (592141) is hosting a DINAH connected to a Kenwood TM-V71A.
If a connection is made from the outside to node 592140, audio is fine in both directions. If a connection is made to node 592141, hosted on the same box, inbound audio is extremely garbled and broken. I tried from a few different systems around the country just to make sure there wasn’t something weird going on here locally.

Just for fun, I set up a private node on that system, attached the DINAH to it instead of node 592141, changed 592141 from simpleusb to DAHDI/pseudo, and connected to that private node from one of my nodes. It sounded great in both directions.
I connected the private node up to 592140, connected to that node instead of the private node from the outside, and, again, it sounded great.
I then tried the same with 592141, and the audio was mangled pretty spectacularly, but only in one direction, as was the case before.

If node 592141 is connected to the private node or 592140, and a call is directed to one of those nodes, everything is fine. The garbled audio only happens when traffic is directed to 592141 from the outside. It doesn’t matter if 592141 is using DAHDI/pseudo or simpleusb.

Another odd thing is that, if I’m connected to 592141, and my friend keys up on 592140, which is also connected to 592141, I can’t hear him at all if he keys up from 592140, unless I connect directly to that node. I just get dead air while he is transmitting.

Honestly, I’m pretty well stumped on this one.

Anyone have a clue what might be going on, or even what I can look for?

Thanks and 73
N2DYI

2

Also just tried changing the rxchannel on node 592140 to simpleusb and physically disconnecting the SHARI and DINAH. Inbound audio is still garbled but only on 592141. No idea.

3

I might start by looking at the codecs. Does ulaw or gsm exist for the node ?

4

All connections established are ulaw, which is preference on both the client and host. GSM is disabled everywhere.

Also, I’ve never encountered a situation where codec priority didn’t affect all nodes on a host. In this case, it’s just the one, which is why I’m especially confused.

5

To me that sounds like one of the USB audio devices is having a hardware problem. Are there any hardware errors in the output of dmesg?

6

No, nothing like that. But the fun part is that only this specific node has the problem even as DAHDI/pseudo taking all the USB hardware out of the equasion. The other two nodes on the same box do not. What?

7

long shot reboot your internet modem and router.

8

If you enable debug logging to the console in /etc/asterisk/logger.conf and then do core set debug 4 app_rpt.so does anything interesting occur on the problematic node that doesn’t on the others?