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

[David McGough]

Patrick,

So, only echolink users are hearing the audio problems when connected to a
HamVoIP node? But, if you record the same audio on that HamVoIP node, it
sounds fine?  Is the incoming audio from an AMBE/IMBE CODEC (i.e.:  from
DVSwitch)??

I know you mention a degrading echolink audio condition with increasing
numbers of users. What happens if an echolink user is getting bad audio
and then all the other echolink users are disconnected, leaving the one
user who was getting bad audio.  After the other users disconnect, leaving
this single user, does their bad audio improve?

Each chan_echolink user runs in a separate thread, so, the processing load 
gets spread across all available CPU cores.

73, David KB4FXC



On Fri, 14 Feb 2020, "Patrick Perdue via ARM-allstar" wrote:

> True, but I can rule out ASL being the problem. I have tested with both 
HamVoIP and ASL in isolated incidents, and can report the same results 
either way.

I did some more tests, and basically, what happens is, for every 
connected echo link node, inbound audio from ASL or HamVoIP audio is 
worse for each successive connection. User 1 gets great audio. User 2 is 
slightly worse. User 3 is worse than that, etc. but all of the echo link 
users sound great coming back to Allstar/HamVoIP, even the ones who get 
really terrible audio back from HamVoIP. So, you won't notice the 
problem if you're only monitoring from the ASL/HamVoIP side of things.

By the way, changing all of the connection points to SLIN made no 
difference in my further tests.


On 2/14/2020 10:41 AM, "David McGough via ARM-allstar" wrote:
> This isn't typical of what I've heard when listening to nets with many
> echolink users, so I'm curious as to what the cause is??
>
> Do remember that the HamVoIP distro is radically different from ASL, from
> a software perspective. ASL or any AllStar running on a cloud-hosted VPS
> is the WORST CASE scenario for bad audio issues. So, don't make a
> generalization assuming that if there is a problem with VPS hosted ASL,
> there will also be the same problems with HamVoIP running on a dedicated
> RPi3 or RPi4 board.
>
> Do you know of a repeatable scenario where bad quality echolink audio can
> be produced?
>
> 73, David KB4FXC
>
>
>
> On Fri, 14 Feb 2020, "W4EDP - Emmett Perdue via ARM-allstar" wrote:
>
>> It’s not just you.  I have one that does the exact same thing and
> have heard many others as well.  Everyone that I have head this issue
> with is based on either Allstar or HamVOIP.
>
> On mine, I have played with every adjustment I can find, I have moved
> URI’s away from radios, I have tried chokes on cables, etc.  Using the
> same radio and a Windows (yuk) based Echolink setup, the problem is 100%
> removed, so it is something related to Echolink and Asterisk or one of
> the modules being used.
>
> As a note, I find what you have found to be true everywhere I have heard
> this issue... Echolink to Echolink is generally good,  Echolink back to
> net is generally good.  Same on number of users, if it’s only 1 or 2,
> generally no issue is heard, as soon as there are 3 or more problems
> starts.  It varies, same person can be “under water” on a
> transmission, then on their next, sound fine.
>
> I’ve searched and searched, I can find others talking about the issue,
> but no solutions and people just live with it hoping one day something
> will change.
>
> 73
> W4EDP
>
>> On Feb 13, 2020, at 7:49 PM, Patrick Perdue via ARM-allstar <arm-allstar at hamvoip.org> 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
>
> _______________________________________________
>
> 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
>
> _______________________________________________
>
> 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
_______________________________________________

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