[arm-allstar] multiple echo link connections and "under water" audio

David McGough kb4fxc at inttek.net
Thu Feb 13 21:33:30 EST 2020


Hi Patrick,

Without diving too deeply into the operational guts of Asterisk/AllStar, 
I'll mention that app_Rpt uses the 8KHz 16-bit SLIN (signed linear) 
audio format internally. So, *ANY* non-SLIN audio coming into Asterisk 
gets transcoded to SLIN, processed by app_Rpt, and then transcoded again 
on the way back out. This may explain some of the artifacts you're 
hearing, however I'm not completely clear on how you've got your system 
linked together?

None of the AllStar channel drivers do any transcoding directly. For 
example, GSM audio samples coming in via chan_echolink pass as GSM all the 
way to the Asterisk core code. Only at that point do they get transcoded 
to SLIN by the Asterisk CODEC layer. Similarly, audio to/from chan_iax2 
gets transported in its native coding format through chan_iax2 to the same 
Asterisk CODEC layer, where it, too, gets converted to SLIN....Then, on 
thru app_Rpt.

Based on premise of avoiding audio degradation due to multiple CODEC's in
the chain, the best possible audio should be provided by sticking with
SLIN between your hubs. Then, no further degradation should occur
(assuming no packet loss!). Since SLIN is pretty high bandwidth, this
strategy is probably most useful only where the hubs are all on the same
high-bandwidth LAN. A very close 2nd in audio quality is uLAW, of course,
with G726 WELL below uLAW, but still usually acceptable----Again, I'm
talking specifically about inter-hub communications.  Certainly GSM, iLBC,
G729, etc., should be avoided for inter-hub links, if possible.

Does this help answer your question?

73, David KB4FXC



On Thu, 13 Feb 2020, "Patrick Perdue via ARM-allstar" wrote:

> Hi all:

     I realize that echo link isn't the primary focus of this group, as 
it relates to HamVoIP, but perhaps some of you may have suggestions.

I'm running a bridge between Allstar, DMR, DSTAR and echo link using 
HamVoIP, DVSwitch and XLXD. I've found that, if only one echo link 
station is connected, audio is as good as it can be, considering the GSM 
codec used by echo link, but subsequent stations hear any audio from 
Allstar as "under water." Echo link to echo link sounds OK, and echo 
link back to Allstar is fine as well.
I've heard this on a few Allstar to echo link bridges other than mine, 
and it sounds like GSM is being transcoded to GSM a second time. You can 
mostly understand what is being said, but the artifacts are doubled. I 
don't really understand how chan_echolink works, or why additional 
transcoding would be happening at that stage, but that's what it sounds 
like to me.

The echo link bridge is on it's own private node. Should I force GSM or 
G726 connections only for that node, or will that just make things worse?

I don't know for sure if it's multiple connections causing this 
behavior, or something else.
My thought, if this is the case, was to limit the echo link channel to 
only 1 connection, and keep it permanently linked to an echo link 
conference server, having people use that instead of my echo link node 
directly, but echo link doesn't seem to like it when people do that.
Any help is appreciated. Feel free to write off-list if you feel this is 
off-topic.
Thanks and 73
de
KE4DYI
_______________________________________________

ARM-allstar mailing list
ARM-allstar at hamvoip.org
http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar

Visit the BBB and RPi2/3/4 web page - http://hamvoip.org



More information about the ARM-allstar mailing list