[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