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
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:
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
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
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(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
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.
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 http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
-- keith@goobie.org Keith Goobie Richmond Hill, ON, CANADA
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 http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
-- 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
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 http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
-- 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
-- keith@goobie.org Keith Goobie Richmond Hill, ON, CANADA
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 http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
-- keith@goobie.org Keith Goobie Richmond Hill, ON, CANADA
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
------------------------------------------------------------------------
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
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
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 http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
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 http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
-- keith@goobie.org Keith Goobie Richmond Hill, ON, CANADA
participants (6)
-
Benjamin L. Naber -
Bryan D. Boyle -
Keith Goobie -
Ken -
REDBUTTON_CTRL -
Robert a. Poff