Audio Clipping with IAXRPT / Web Transceiver Client

AllStarLink
1

Audio Clipping with IAXRPT / Web Transceiver Client
Good day All.

We have had our node up at VE3LSR / VE3UOR for a few months and we all have learned a lot about configuration and operation. It is ACID install and version id is 300.3.

On our asterisk system, we support three nodes:

27211 – VE3UOR UHF repeater

29133 – VE3LSR coupled through a RLC-DSP404 controller (often connected to VE3UPS and VE3UHN), and

29154 – VA3LSR remote link for VE3LSR into VE3MUS – not too active – ad-hoc RF link.

I have also been testing out iaxrpt and the WebTransceiver clients.

I am on these systems and the results have been promising. I do notice some clipping on the audio on some stations. Initially I thought it was amplitude related – over-driving the URI-FOB, but I am now beginning to suspect that it may be network related and in my research I hear the term jitter being used – which if activated, adjust operation on the receiving end only.

It may be that the system is not powered enough to drive the three uri-fobs. CPU show about 25% busy.

[root@VE3LSR etc]# cat /proc/cpuinfo

processor : 0

vendor_id : GenuineIntel

cpu family : 15

model : 4

model name : Intel® Pentium® 4 CPU 3.00GHz

stepping : 3

cpu MHz : 2992.898

cache size : 2048 KB

physical id : 0

siblings : 2

core id : 0

cpu cores : 1

apicid : 0

fdiv_bug : no

hlt_bug : no

f00f_bug : no

coma_bug : no

fpu : yes

fpu_exception : yes

cpuid level : 5

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr

bogomips : 5985.79

We do think that the system is sufficiently powered.

We are looking for comments & guidance. Are we expecting too much from the system having three fobs connected? We do have good bandwidth into and out of the site.

I am listening to other systems – most not to busy, so I am not yet able to get a good reference point.

I have not dabbled with the codecs much, but have been focused on using ulaw. I am also testing with GSM – lower bandwidth.

So as I said before, thoughts or suggestions are welcome.

Keith / VA3YC

···

–

keith@goobie.org

Keith Goobie

Richmond Hill, ON, CANADA

2

Hi Kieth, In the usbradio.conf have you got the "txlinonly = yes’?

This should limit TX audio coming from the URI.

txlimonly=yes        ; Audio limiting with no pre-emphasis on output

channel: no,yes

            ; no - Audio is not limited.

            ; yes - Audio is  limited.

            ; Suitable for transmitters with no limiting but with

pre-emphasis.

You can also tell the IAX users to cut back their mic gains. I would

start here first. Like a lot of people on Echolink they dont have
the computer set up properly. I find that head sets sound the best
rather than using the internal mics on lapatops.

I would leave the codec as Ulaw. dont bother with GSM, has crappy

watery audio.

Jon VA3RQ
···

App_rpt-users@ohnosec.orghttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

3

Re: [App_rpt-users] Audio Clipping with IAXRPT / Web Transceiver Client
Hi Jon

Just checked the configs -

All three appearances (we control three URI fobs) of txlinonly are commented out, do you know what the default is.

Incoming audio from iaxrpt users seems OK, with no issues.

Keith

···

On 3/3/13 11:41 AM, “REDBUTTON_CTRL” jrorke@cogeco.ca wrote:

Hi Kieth, In the usbradio.conf have you got the "txlinonly = yes’?

This should limit TX audio coming from the URI.

txlimonly=yes ; Audio limiting with no pre-emphasis on output channel: no,yes

         ; no - Audio is not limited.

         ; yes - Audio is  limited.

         ; Suitable for transmitters with no limiting but with pre-emphasis.

You can also tell the IAX users to cut back their mic gains. I would start here first. Like a lot of people on Echolink they dont have the computer set up properly. I find that head sets sound the best rather than using the internal mics on lapatops.

I would leave the codec as Ulaw. dont bother with GSM, has crappy watery audio.

Jon VA3RQ

On 3/3/2013 11:31 AM, Keith Goobie wrote:

Audio Clipping with IAXRPT / Web Transceiver Client Good day All.

We have had our node up at VE3LSR / VE3UOR for a few months and we all have learned a lot about configuration and operation. It is ACID install and version id is 300.3.

On our asterisk system, we support three nodes:

27211 – VE3UOR UHF repeater

29133 – VE3LSR coupled through a RLC-DSP404 controller (often connected to VE3UPS and VE3UHN), and

29154 – VA3LSR remote link for VE3LSR into VE3MUS – not too active – ad-hoc RF link.

I have also been testing out iaxrpt and the WebTransceiver clients.

I am on these systems and the results have been promising. I do notice some clipping on the audio on some stations. Initially I thought it was amplitude related – over-driving the URI-FOB, but I am now beginning to suspect that it may be network related and in my research I hear the term jitter being used – which if activated, adjust operation on the receiving end only.

It may be that the system is not powered enough to drive the three uri-fobs. CPU show about 25% busy.

[root@VE3LSR etc]# cat /proc/cpuinfo

processor : 0

vendor_id : GenuineIntel

cpu family : 15

model : 4

model name : Intel(R) Pentium(R) 4 CPU 3.00GHz

stepping : 3

cpu MHz : 2992.898

cache size : 2048 KB

physical id : 0

siblings : 2

core id : 0

cpu cores : 1

apicid : 0

fdiv_bug : no

hlt_bug : no

f00f_bug : no

coma_bug : no

fpu : yes

fpu_exception : yes

cpuid level : 5

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr

bogomips : 5985.79

We do think that the system is sufficiently powered.

We are looking for comments & guidance. Are we expecting too much from the system having three fobs connected? We do have good bandwidth into and out of the site.

I am listening to other systems – most not to busy, so I am not yet able to get a good reference point.

I have not dabbled with the codecs much, but have been focused on using ulaw. I am also testing with GSM – lower bandwidth.

So as I said before, thoughts or suggestions are welcome.

Keith / VA3YC

–

keith@goobie.org

Keith Goobie

Richmond Hill, ON, CANADA

App_rpt-users mailing list

App_rpt-users@ohnosec.org

http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

App_rpt-users mailing list

App_rpt-users@ohnosec.org

http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

–

keith@goobie.org

Keith Goobie

Richmond Hill, ON, CANADA

4

Audio Clipping with IAXRPT / Web Transceiver ClientDoes the clipping occur usually on the same stations?

Or sort of randomly?

In addition to CPU load, how much free memory do you have?

I was told that you should have enough memory to not see ANY swapping.

And found that to be a good rule of thumb.

The time involved with disk access comes into play.

···

Keith Goobie keith@goobie.org wrote:

Good day All.

We have had our node up at VE3LSR / VE3UOR for a few months and we all have learned a lot about configuration and operation. It is ACID install and version id is 300.3.

On our asterisk system, we support three nodes:

27211 – VE3UOR UHF repeater

29133 – VE3LSR coupled through a RLC-DSP404 controller (often connected to VE3UPS and VE3UHN), and

29154 – VA3LSR remote link for VE3LSR into VE3MUS – not too active – ad-hoc RF link.

I have also been testing out iaxrpt and the WebTransceiver clients.

I am on these systems and the results have been promising. I do notice some clipping on the audio on some stations. Initially I thought it was amplitude related – over-driving the URI-FOB, but I am now beginning to suspect that it may be network related and in my research I hear the term jitter being used – which if activated, adjust operation on the receiving end only.

It may be that the system is not powered enough to drive the three uri-fobs. CPU show about 25% busy.

[root@VE3LSR etc]# cat /proc/cpuinfo

processor : 0

vendor_id : GenuineIntel

cpu family : 15

model : 4

model name : Intel(R) Pentium(R) 4 CPU 3.00GHz

stepping : 3

cpu MHz : 2992.898

cache size : 2048 KB

physical id : 0

siblings : 2

core id : 0

cpu cores : 1

apicid : 0

fdiv_bug : no

hlt_bug : no

f00f_bug : no

coma_bug : no

fpu : yes

fpu_exception : yes

cpuid level : 5

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr

bogomips : 5985.79

We do think that the system is sufficiently powered.

We are looking for comments & guidance. Are we expecting too much from the system having three fobs connected? We do have good bandwidth into and out of the site.

I am listening to other systems – most not to busy, so I am not yet able to get a good reference point.

I have not dabbled with the codecs much, but have been focused on using ulaw. I am also testing with GSM – lower bandwidth.

So as I said before, thoughts or suggestions are welcome.

Keith / VA3YC

–

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

5

Re: [App_rpt-users] Audio Clipping with IAXRPT / Web Transceiver Client
Hi Robert

Memory on the system is 1GB ram

When I run free I get -

[root@VE3LSR asterisk]# free

         total       used       free     shared    buffers     cached

Mem: 1034368 628924 405444 0 185776 289968

-/+ buffers/cache: 153180 881188

Swap: 1020116 0 1020116

[root@VE3LSR asterisk]#

The attached drive is a SSD

Clipping can occur randomly – it is not tied to one station. Volume levels on these stations can vary.

We have good bandwidth into out of the site. Co-located with an ISP.

We are using the DMK fobs.

Keith

···

On 3/3/13 12:48 PM, “Robert a. Poff” wb3awj@comcast.net wrote:

Does the clipping occur usually on the same stations?

Or sort of randomly?

In addition to CPU load, how much free memory do you have?

I was told that you should have enough memory to not see ANY swapping.

And found that to be a good rule of thumb.

The time involved with disk access comes into play.

Keith Goobie keith@goobie.org wrote:

Good day All.

We have had our node up at VE3LSR / VE3UOR for a few months and we all have learned a lot about configuration and operation. It is ACID install and version id is 300.3.

On our asterisk system, we support three nodes:

27211 – VE3UOR UHF repeater

29133 – VE3LSR coupled through a RLC-DSP404 controller (often connected to VE3UPS and VE3UHN), and

29154 – VA3LSR remote link for VE3LSR into VE3MUS – not too active – ad-hoc RF link.

I have also been testing out iaxrpt and the WebTransceiver clients.

I am on these systems and the results have been promising. I do notice some clipping on the audio on some stations. Initially I thought it was amplitude related – over-driving the URI-FOB, but I am now beginning to suspect that it may be network related and in my research I hear the term jitter being used – which if activated, adjust operation on the receiving end only.

It may be that the system is not powered enough to drive the three uri-fobs. CPU show about 25% busy.

[root@VE3LSR etc]# cat /proc/cpuinfo

processor : 0

vendor_id : GenuineIntel

cpu family : 15

model : 4

model name : Intel(R) Pentium(R) 4 CPU 3.00GHz

stepping : 3

cpu MHz : 2992.898

cache size : 2048 KB

physical id : 0

siblings : 2

core id : 0

cpu cores : 1

apicid : 0

fdiv_bug : no

hlt_bug : no

f00f_bug : no

coma_bug : no

fpu : yes

fpu_exception : yes

cpuid level : 5

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr

bogomips : 5985.79

We do think that the system is sufficiently powered.

We are looking for comments & guidance. Are we expecting too much from the system having three fobs connected? We do have good bandwidth into and out of the site.

I am listening to other systems – most not to busy, so I am not yet able to get a good reference point.

I have not dabbled with the codecs much, but have been focused on using ulaw. I am also testing with GSM – lower bandwidth.

So as I said before, thoughts or suggestions are welcome.

Keith / VA3YC

–

keith@goobie.org

Keith Goobie

Richmond Hill, ON, CANADA

6

Re: [App_rpt-users] Audio Clipping with IAXRPT / Web Transceiver Client
If you have a system where you drive the modulator directly and use

txprelim=yes

  •      then you already have limiting

If not, and you are using “microphone audio” then you should un-comment

txlimonly=yes

it is quite possible to overdrive the URI and it sounds nasty when it happens.

(You should check that the values for txtone and txvoice that you used in your audio calibration add up to a number less than 1000).

GL

Ken

···

From: app_rpt-users-bounces@ohnosec.org [mailto:app_rpt-users-bounces@ohnosec.org] On Behalf Of Keith Goobie
Sent: Sunday, March 03, 2013 12:19 PM
To: REDBUTTON_CTRL
Cc: APP RPT
Subject: Re: [App_rpt-users] Audio Clipping with IAXRPT / Web Transceiver Client

Hi Jon

Just checked the configs -

All three appearances (we control three URI fobs) of txlinonly are commented out, do you know what the default is.

Incoming audio from iaxrpt users seems OK, with no issues.

Keith

On 3/3/13 11:41 AM, “REDBUTTON_CTRL” jrorke@cogeco.ca wrote:

Hi Kieth, In the usbradio.conf have you got the "txlinonly = yes’?

This should limit TX audio coming from the URI.

txlimonly=yes ; Audio limiting with no pre-emphasis on output channel: no,yes
; no - Audio is not limited.
; yes - Audio is limited.
; Suitable for transmitters with no limiting but with pre-emphasis.

You can also tell the IAX users to cut back their mic gains. I would start here first. Like a lot of people on Echolink they dont have the computer set up properly. I find that head sets sound the best rather than using the internal mics on lapatops.

I would leave the codec as Ulaw. dont bother with GSM, has crappy watery audio.

Jon VA3RQ

On 3/3/2013 11:31 AM, Keith Goobie wrote:

Audio Clipping with IAXRPT / Web Transceiver Client Good day All.

We have had our node up at VE3LSR / VE3UOR for a few months and we all have learned a lot about configuration and operation. It is ACID install and version id is 300.3.

On our asterisk system, we support three nodes:

27211 – VE3UOR UHF repeater
29133 – VE3LSR coupled through a RLC-DSP404 controller (often connected to VE3UPS and VE3UHN), and
29154 – VA3LSR remote link for VE3LSR into VE3MUS – not too active – ad-hoc RF link.

I have also been testing out iaxrpt and the WebTransceiver clients.

I am on these systems and the results have been promising. I do notice some clipping on the audio on some stations. Initially I thought it was amplitude related – over-driving the URI-FOB, but I am now beginning to suspect that it may be network related and in my research I hear the term jitter being used – which if activated, adjust operation on the receiving end only.

It may be that the system is not powered enough to drive the three uri-fobs. CPU show about 25% busy.
[root@VE3LSR etc]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel® Pentium® 4 CPU 3.00GHz
stepping : 3
cpu MHz : 2992.898
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr
bogomips : 5985.79

We do think that the system is sufficiently powered.

We are looking for comments & guidance. Are we expecting too much from the system having three fobs connected? We do have good bandwidth into and out of the site.

I am listening to other systems – most not to busy, so I am not yet able to get a good reference point.

I have not dabbled with the codecs much, but have been focused on using ulaw. I am also testing with GSM – lower bandwidth.

So as I said before, thoughts or suggestions are welcome.

Keith / VA3YC

keith@goobie.org
Keith Goobie
Richmond Hill, ON, CANADA

App_rpt-users mailing list
App_rpt-users@ohnosec.org
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

App_rpt-users mailing list
App_rpt-users@ohnosec.org
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

–
keith@goobie.org
Keith Goobie
Richmond Hill, ON, CANADA

7

One other thing to check...which I'm surprised no one has mentioned, is
that frequently the motherboard USB ports are crap. Plain and simple.
I had the same problem, which I traced down to a 'value engineered'
(read as cheap as possible implementation) set of USB ports on my HP
computer (who knows whose motherboard) which gave me choppy audio, cut
outs, etc., which simulated overdriving/limiting apparently on the
systems connected.

Spent (OMG, there's that word in a ham discussion) 40 bucks for an
add-on USB adapter board. 4 ports. USB 2.0 capable. Problem went away.

Just some other things to check.

Bryan WB0YLE
Allstar 27295 27295 27710 etc.

···

On 3/3/2013 12:18 PM, Keith Goobie wrote:

Hi Jon

Just checked the configs -

All three appearances (we control three URI fobs) of txlinonly are commented
out, do you know what the default is.

Incoming audio from iaxrpt users seems OK, with no issues.

Keith

8

Hi Bryan

Thanks for the input on the limitations of some USB hubs. I have seen that
before on another project. In some cases I went back to plain old serial
ports, but that is not possible here.

I will keep my eyes open for error messaging in that regard.

One suggestion, I did receive was to remove the rxboost and I have done
that. I think it has helped and I am monitoring it. This would suggest
that the problem was amplitude related and not jitter where I was trying to
point myself.

There will be more to follow.

Again thanks to all for their feedback.

Keith

···

On 3/3/13 3:52 PM, "Bryan D. Boyle" <bdboyle@bdboyle.com> wrote:

On 3/3/2013 12:18 PM, Keith Goobie wrote:

Hi Jon

Just checked the configs -

All three appearances (we control three URI fobs) of txlinonly are commented
out, do you know what the default is.

Incoming audio from iaxrpt users seems OK, with no issues.

Keith

One other thing to check...which I'm surprised no one has mentioned, is
that frequently the motherboard USB ports are crap. Plain and simple.
I had the same problem, which I traced down to a 'value engineered'
(read as cheap as possible implementation) set of USB ports on my HP
computer (who knows whose motherboard) which gave me choppy audio, cut
outs, etc., which simulated overdriving/limiting apparently on the
systems connected.

Spent (OMG, there's that word in a ham discussion) 40 bucks for an
add-on USB adapter board. 4 ports. USB 2.0 capable. Problem went away.

Just some other things to check.

Bryan WB0YLE
Allstar 27295 27295 27710 etc.

_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
ohnosec.org

--
keith@goobie.org
Keith Goobie
Richmond Hill, ON, CANADA

9

Yes I guess you could clobber the input side ... a symptom of that is when
you run "radio tune rxnoise" you would not be able to get a reasonable
setting for the receive gain (rxmixerset= in the radio_tune_usbxxx file).

Ideally that gain setting should be somewhere in the middle of the range
(say 200-800).

Regards

Ken

(You did run the calibration again after turning off rxboost, right?)

From: app_rpt-users-bounces@ohnosec.org [mailto:app_rpt-users-
bounces@ohnosec.org] On Behalf Of Keith Goobie
Sent: Sunday, March 03, 2013 4:00 PM
To: Bryan D. Boyle; app_rpt mailing list
Subject: Re: [App_rpt-users] Audio Clipping with IAXRPT / Web Transceiver
Client

Hi Bryan

Thanks for the input on the limitations of some USB hubs. I have seen

that

before on another project. In some cases I went back to plain old serial
ports, but that is not possible here.

I will keep my eyes open for error messaging in that regard.

One suggestion, I did receive was to remove the rxboost and I have done
that. I think it has helped and I am monitoring it. This would suggest

that the

problem was amplitude related and not jitter where I was trying to point
myself.

There will be more to follow.

Again thanks to all for their feedback.

Keith

>> Hi Jon
>>
>> Just checked the configs -
>>
>> All three appearances (we control three URI fobs) of txlinonly are
>> commented out, do you know what the default is.
>>
>> Incoming audio from iaxrpt users seems OK, with no issues.
>>
>> Keith
>
> One other thing to check...which I'm surprised no one has mentioned,
> is that frequently the motherboard USB ports are crap. Plain and

simple.

> I had the same problem, which I traced down to a 'value engineered'
> (read as cheap as possible implementation) set of USB ports on my HP
> computer (who knows whose motherboard) which gave me choppy audio,
cut
> outs, etc., which simulated overdriving/limiting apparently on the
> systems connected.
>
> Spent (OMG, there's that word in a ham discussion) 40 bucks for an
> add-on USB adapter board. 4 ports. USB 2.0 capable. Problem went

away.

···

-----Original Message-----
On 3/3/13 3:52 PM, "Bryan D. Boyle" <bdboyle@bdboyle.com> wrote:
> On 3/3/2013 12:18 PM, Keith Goobie wrote:
>
> Just some other things to check.
>
> Bryan WB0YLE
> Allstar 27295 27295 27710 etc.
>
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users@ohnosec.org
> ohnosec.org

--
keith@goobie.org
Keith Goobie
Richmond Hill, ON, CANADA

_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
ohnosec.org

10

Ken

We had to do it by ear today - not the preferred approach. It will require
a trip to the site with the test gear. We are much better in the ball park.

Trip is to be planned = we are fortunate that we have remote access to the
various elements that make up the system. This is how it was configured
with the test equipment a few months ago.

[root@VE3LSR asterisk]# cat usbradio_tune_usb1.conf
[usb1]
; name=usb1
; devicenum=1
devstr=2-2
rxmixerset=500
txmixaset=750
txmixbset=500
rxvoiceadj=2.186060
rxctcssadj=0.500000
txctcssadj=200
rxsquelchadj=500
[root@VE3LSR asterisk]#

More to follow

Keith

···

On 3/3/13 5:00 PM, "Ken" <ke2n@cs.com> wrote:

Yes I guess you could clobber the input side ... a symptom of that is when
you run "radio tune rxnoise" you would not be able to get a reasonable
setting for the receive gain (rxmixerset= in the radio_tune_usbxxx file).

Ideally that gain setting should be somewhere in the middle of the range
(say 200-800).

Regards

Ken

(You did run the calibration again after turning off rxboost, right?)

-----Original Message-----
From: app_rpt-users-bounces@ohnosec.org [mailto:app_rpt-users-
bounces@ohnosec.org] On Behalf Of Keith Goobie
Sent: Sunday, March 03, 2013 4:00 PM
To: Bryan D. Boyle; app_rpt mailing list
Subject: Re: [App_rpt-users] Audio Clipping with IAXRPT / Web Transceiver
Client

Hi Bryan

Thanks for the input on the limitations of some USB hubs. I have seen

that

before on another project. In some cases I went back to plain old serial
ports, but that is not possible here.

I will keep my eyes open for error messaging in that regard.

One suggestion, I did receive was to remove the rxboost and I have done
that. I think it has helped and I am monitoring it. This would suggest

that the

problem was amplitude related and not jitter where I was trying to point
myself.

There will be more to follow.

Again thanks to all for their feedback.

Keith

On 3/3/13 3:52 PM, "Bryan D. Boyle" <bdboyle@bdboyle.com> wrote:

On 3/3/2013 12:18 PM, Keith Goobie wrote:

Hi Jon

Just checked the configs -

All three appearances (we control three URI fobs) of txlinonly are
commented out, do you know what the default is.

Incoming audio from iaxrpt users seems OK, with no issues.

Keith

One other thing to check...which I'm surprised no one has mentioned,
is that frequently the motherboard USB ports are crap. Plain and

simple.

I had the same problem, which I traced down to a 'value engineered'
(read as cheap as possible implementation) set of USB ports on my HP
computer (who knows whose motherboard) which gave me choppy audio,

cut

outs, etc., which simulated overdriving/limiting apparently on the
systems connected.

Spent (OMG, there's that word in a ham discussion) 40 bucks for an
add-on USB adapter board. 4 ports. USB 2.0 capable. Problem went

away.

Just some other things to check.

Bryan WB0YLE
Allstar 27295 27295 27710 etc.

_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
ohnosec.org

--
keith@goobie.org
Keith Goobie
Richmond Hill, ON, CANADA

_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
ohnosec.org

--
keith@goobie.org
Keith Goobie
Richmond Hill, ON, CANADA

11

Somethings I would check on.

Use the radio-tune-menu to ensure with a service monitor to ensure the
TX and RX audio levels correctly. Remove any possibility the "Distant
End" is having difficulty.

Also, while you might still have a great internet connection, you may
still suffer poor VoIP service because of Quality of Service (QoS)
implemented on the routers you are connected to. I've run into many
businesses with 50-100Mb internet connections and the VoIP audio sucks
because there was no prioritization of VoIP packets.

Test your setup with stations that have properly set audio levels, via
RF, and connected to another node. Allstar nodes 2130 and 2560 seem to
have their stuff together. You also be able to call into the Allstar
telephone portal (763) 230-0000, and connect to your node that way to do
some "for grins" testing.

What is beyond anyone's reasonable control is whether or not the users
of your system, or anyones for that matter, have properly set audio
levels on their rigs. HTs seem to be the biggest offenders of having
mis-tuned TX audio.

As mentioned before, you do not need to have a real power node to run
Allstar. I run Limey Linux on a 1GHz thin client with zero problems. I
have my router setup for QoS of VoIP packets, and so far I've had zero
issues with any type of audio issues.

~Benjamin, KB9LFZ
Allstar 28569

···

On Sun, 2013-03-03 at 11:31 -0500, Keith Goobie wrote:

Good day All.

We have had our node up at VE3LSR / VE3UOR for a few months and we all
have learned a lot about configuration and operation. It is ACID
install and version id is 300.3.

On our asterisk system, we support three nodes:

27211 – VE3UOR UHF repeater
29133 – VE3LSR coupled through a RLC-DSP404 controller (often
connected to VE3UPS and VE3UHN), and
29154 – VA3LSR remote link for VE3LSR into VE3MUS – not too active –
ad-hoc RF link.

I have also been testing out iaxrpt and the WebTransceiver clients.

I am on these systems and the results have been promising. I do
notice some clipping on the audio on some stations. Initially I
thought it was amplitude related – over-driving the URI-FOB, but I am
now beginning to suspect that it may be network related and in my
research I hear the term jitter being used – which if activated,
adjust operation on the receiving end only.

It may be that the system is not powered enough to drive the three
uri-fobs. CPU show about 25% busy.
[root@VE3LSR etc]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping : 3
cpu MHz : 2992.898
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm
constant_tsc pni monitor ds_cpl est cid cx16 xtpr
bogomips : 5985.79

We do think that the system is sufficiently powered.

We are looking for comments & guidance. Are we expecting too much
from the system having three fobs connected? We do have good
bandwidth into and out of the site.

I am listening to other systems – most not to busy, so I am not yet
able to get a good reference point.

I have not dabbled with the codecs much, but have been focused on
using ulaw. I am also testing with GSM – lower bandwidth.

So as I said before, thoughts or suggestions are welcome.

Keith / VA3YC
--
keith@goobie.org
Keith Goobie
Richmond Hill, ON, CANADA
_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
ohnosec.org

12

Benjamin

I have an RV042 router and I have established priority handling for iAX VoIP
packets.

WE will get a service monitor into play. We just have to schedule some site
time.

I do agree that there are a lot of variables out there.

WE do have some nodes to reference locally.

Keith

···

On 3/3/13 8:03 PM, "Benjamin L. Naber" <Benjamin@kb9lfz.com> wrote:

Somethings I would check on.

Use the radio-tune-menu to ensure with a service monitor to ensure the
TX and RX audio levels correctly. Remove any possibility the "Distant
End" is having difficulty.

Also, while you might still have a great internet connection, you may
still suffer poor VoIP service because of Quality of Service (QoS)
implemented on the routers you are connected to. I've run into many
businesses with 50-100Mb internet connections and the VoIP audio sucks
because there was no prioritization of VoIP packets.

Test your setup with stations that have properly set audio levels, via
RF, and connected to another node. Allstar nodes 2130 and 2560 seem to
have their stuff together. You also be able to call into the Allstar
telephone portal (763) 230-0000, and connect to your node that way to do
some "for grins" testing.

What is beyond anyone's reasonable control is whether or not the users
of your system, or anyones for that matter, have properly set audio
levels on their rigs. HTs seem to be the biggest offenders of having
mis-tuned TX audio.

As mentioned before, you do not need to have a real power node to run
Allstar. I run Limey Linux on a 1GHz thin client with zero problems. I
have my router setup for QoS of VoIP packets, and so far I've had zero
issues with any type of audio issues.

~Benjamin, KB9LFZ
Allstar 28569

On Sun, 2013-03-03 at 11:31 -0500, Keith Goobie wrote:

Good day All.

We have had our node up at VE3LSR / VE3UOR for a few months and we all
have learned a lot about configuration and operation. It is ACID
install and version id is 300.3.

On our asterisk system, we support three nodes:

27211 ­ VE3UOR UHF repeater
29133 ­ VE3LSR coupled through a RLC-DSP404 controller (often
connected to VE3UPS and VE3UHN), and
29154 ­ VA3LSR remote link for VE3LSR into VE3MUS ­ not too active ­
ad-hoc RF link.

I have also been testing out iaxrpt and the WebTransceiver clients.

I am on these systems and the results have been promising. I do
notice some clipping on the audio on some stations. Initially I
thought it was amplitude related ­ over-driving the URI-FOB, but I am
now beginning to suspect that it may be network related and in my
research I hear the term jitter being used ­ which if activated,
adjust operation on the receiving end only.

It may be that the system is not powered enough to drive the three
uri-fobs. CPU show about 25% busy.
[root@VE3LSR etc]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping : 3
cpu MHz : 2992.898
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm
constant_tsc pni monitor ds_cpl est cid cx16 xtpr
bogomips : 5985.79

We do think that the system is sufficiently powered.

We are looking for comments & guidance. Are we expecting too much
from the system having three fobs connected? We do have good
bandwidth into and out of the site.

I am listening to other systems ­ most not to busy, so I am not yet
able to get a good reference point.

I have not dabbled with the codecs much, but have been focused on
using ulaw. I am also testing with GSM ­ lower bandwidth.

So as I said before, thoughts or suggestions are welcome.

Keith / VA3YC
--
keith@goobie.org
Keith Goobie
Richmond Hill, ON, CANADA
_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
ohnosec.org

--
keith@goobie.org
Keith Goobie
Richmond Hill, ON, CANADA

13

Bryan

I dug up a usbmon utility and found that the DMK URI fobs are all connected
at USB 1.1 / 12 Mbps, and two of the three are on the same hub. I
definitely think that there will be a USB 2.0 card in our future.

This is a recent computer I thought, but have been fooled. A new crad will
be a small investment.

Keith

···

On 3/3/13 3:52 PM, "Bryan D. Boyle" <bdboyle@bdboyle.com> wrote:

On 3/3/2013 12:18 PM, Keith Goobie wrote:

Hi Jon

Just checked the configs -

All three appearances (we control three URI fobs) of txlinonly are commented
out, do you know what the default is.

Incoming audio from iaxrpt users seems OK, with no issues.

Keith

One other thing to check...which I'm surprised no one has mentioned, is
that frequently the motherboard USB ports are crap. Plain and simple.
I had the same problem, which I traced down to a 'value engineered'
(read as cheap as possible implementation) set of USB ports on my HP
computer (who knows whose motherboard) which gave me choppy audio, cut
outs, etc., which simulated overdriving/limiting apparently on the
systems connected.

Spent (OMG, there's that word in a ham discussion) 40 bucks for an
add-on USB adapter board. 4 ports. USB 2.0 capable. Problem went away.

Just some other things to check.

Bryan WB0YLE
Allstar 27295 27295 27710 etc.

_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
ohnosec.org

--
keith@goobie.org
Keith Goobie
Richmond Hill, ON, CANADA