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