[arm-allstar] [Spam?] Re: Workaround for variable audio delay

[LaRoy McCann]

David,

Please don't think I'm knocking the hamvoip release.
I've been running it for about a year now and I love it.
I've been telling everyone I know that is involved with repeaters about it.
I really appreciate the work you guys have done.

I know how busy life gets.  I work full time for a living and also 
singlehandedly run a WISP (with a little help from the wife).
Oh, don't forget trying to "play radio" in all my spare time.

I know you have a fix for the problem but as of last week when I started 
playing with DIAL did not know any timeline for release of the fix.

LaRoy McCann, K5TW

On 1/18/2016 1:54 PM, David McGough wrote:
> Hi LaRoy,
>
> Yes, using usbradio is an option over simpleusb for resolving the variable
> audio delay. As you have found, usbradio does work in the hamvoip release.
> And, usbradio can be used, if you're will to put up with a extra audio
> artifacts here and there--I expect this noise is easy for me to hear,
> since I've become accustom to listening for these artifacts during
> software development and tuning...But, usbradio IS indeed usable.
>
> As for reported CPU use differences, I expect this is mainly due to -all-
> the reporting software and Linux Kernel found in the hamvoip release being
> more recent than the equivalents included in the Debian version....YES,
> that's correct: the hamvoip release uses a NEWER kernel, libraries,
> etc., even though it was released maybe 6 months earlier!  This is the
> advantage you get by using the Arch disto: it is truly (b)leading edge.
> Since the RPi2 device drivers have been rapidly evolving, (b)leading edge
> is typically a good thing...
>
> Also, there is nothing wrong with disabling unused Asterisk modules in
> hamvoip release, similar as found in the Debian version--this -might-
> provide a small performance boost. It's worth nothing that these modules
> are multi-threaded and on the RPi2, there are four parallel cores. So, I
> expect any performance gain to be marginal, likely not even noticeable
> (but, I welcome someone to prove me wrong about this!!!).
>
> Anyhow, as has been mentioned on the e-mail list, there is already a beta
> simpleusb driver available that resolves the variable audio delay. It will
> work ONLY with the stock hamvoip RPi2 1.0 release and is available on a
> limited basis to those who wish to be Guinea Pigs....AH, I MEAN -beta
> testers- LOL.  (Please contact off list for more info).
>
> 73, David KB4FXC
>
>
>
> On Mon, 18 Jan 2016, LaRoy McCann wrote:
>
>> I know there is a fix for the variable audio delay in testing and I look
>> forward to it being released.
>>
>> In the meantime....
>> I have been playing around and I think I have found a workaround for the
>> problem.
>> At least it works for me.
>>
>> I know the general rule of thumb is to use simpleusb instead of radiousb
>> because it puts less load on the cpu.
>> I noticed in the config file for radiousb that you can still use the
>> hardwired inputs for cor and ctcss.
>> Well, I decided to try radiousb to see what would happen.
>>
>> I am using RP2 and only one full duplex repeater on each system.
>> I have two systems that are linked together full time via the internet.
>> One is running Arm Allstar image and the other is running DIAL image.
>>
>> Arm Allstar Image:
>>     What I have done is switched to using radiousb instead of simpleusb.
>>     I use the hardwired input for cor.  (carrierfrom=usb)
>>     I also use the hardwired input for ctcss.  (ctcssfrom=usb)
>>
>> DIAL Image:
>>     What I have done is switched to using radiousb instead of simpleusb.
>>     I use the hardwired input for cor.  (carrierfrom=usb)
>>     I use dsp for ctcss.  (ctcssfrom=dsp)
>>
>> I am actually using dsp on the DIAL image for ctcss.  I thought I would
>> try this since I did not have a tone board on this repeater yet.
>> It seems to work well decoding the ctcss.
>>
>>
>> I know top is a different version between the two systems but on DIAL
>> the cpu load only runs about 3.6% cpu compaired to Arm Allstar which can
>> run around 25-26% cpu.
>> It's hard to tell on Arm Allstar because top breaks down each cpu usage
>> where DIAL's version only shows the total cpu usage.
>>
>> I noticed that on DIAL all modules are not loaded by default.  This
>> probably contributes to less of a load on the cpu.
>>
>>
>> I have been running the DIAL system this way for about a week and the
>> Arm Allstar system since yesterday.
>> It seems to have cured the variable audio delay issues for me.
>> I do not hear any dropped or choppy audio.
>>
>>
>> LaRoy McCann, K5TW
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>> _______________________________________________
>>
>> arm-allstar mailing list
>> arm-allstar at hamvoip.org
>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>
>> Visit the BBB and RPi2 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 web page - http://hamvoip.org
>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus