<div><br></div>When I started using this software I noticed the audio issues in my test environment.  I tried a dozen different mothertboard/CPU combinations and 3 different USB fobs.  I found that the faster the system the less noticeable the issues but even a 3.4 GHZ quad core still had the issues.  I experimented with a lot of variables and several things made some difference but the single most significant thing that reduced the issue was stopping ntpd.  I now run ntpdate 40 seconds after the hour, every hour.  This keeps the date and time close enough and greatly reduces the audio glitch like sounds that I was noticing.  Also I found that when the system is not under test and is using real hand held and mobile stations working through the repeater that the remaining audio glitch like sounds are indistinguishable from typical normal radio noise hits.  By the way, my final choice for a system board is the D510MO.<div>

While I do not know for sure, I suspect that when ntpd makes tiny adjustments to the system time, this results in tiny glitches in the processing in the USB sound system.  I am clueless how to track it down any further, and do not see any need.</div>

<div>Chuck<br><br><div class="gmail_quote">On Wed, Feb 16, 2011 at 12:21 PM, Steve Gladden <span dir="ltr"><<a href="mailto:steve@michiganbroadband.com">steve@michiganbroadband.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I see those same type of audio issues with fast processors & slow processors.<br>
<br>
I've been told it's because of how Linux and USB works (or does not work)<br>
for that matter.<br>
<br>
And I have been told the USB interface is not a production quality solution.<br>
<br>
I wish I better understood this first hand but currently  do not.<br>
<br>
I have a lot of personal suspicions of what it might involve but do not<br>
have the software technical know how to test & measure the kernel &<br>
software<br>
activity going on while the audio anomolies occur.. versus while<br>
they are NOT occurring.<br>
<br>
<br>
I have a lot of those --it might be this or it might be that thoughts but<br>
nothing to back it up or do much about it at this time..<br>
Might even be fault Asterisk itself or Zaptel interaction with the channel<br>
driver for instance :-)<br>
<br>
I am at a point where if one (or more) of the developers feels like<br>
digging in I'd happily purchase the EXACT same hardware they are<br>
developing on/working with so that I could be more helpful in<br>
troubleshooting this and reporting issues that could easily be reproduced<br>
 that would happen for the devs the same way.<br>
<br>
Although I *think* this is happening across the board to some degree.<br>
(from my own testing on multiple systems and my interaction with other users)<br>
It's subtle under normal use and most operators don't notice it or it's<br>
just not service affecting enough to have become a primary concern.<br>
<br>
It's a miracle the software is here and works and as-is<br>
and that's its been made available for free and is getting constant<br>
cool & useful updates at user's requests..<br>
That's very col & exciting.<br>
<br>
The Happiness/Grief ratio (H/G) is very high in this area :-)<br>
<br>
But yes I'd like to see the audio output to Transmitter work perfectly<br>
And work toward that end If it's possible.<br>
Or at least understand first hand what gives.<br>
<br>
I don't want to complain out here I'd like to learn something.<br>
This type of software and building on it is the present and<br>
future of Radio/TeleCommunications amateur and professional.<br>
I plan to be involved, be useful and enjoy the hell out of it.<br>
<br>
-Steve<br>
<div><div></div><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
>>BTW- runing full duplex chan_usbradio on a Pentium-3 733MHz box<br>
>>I see 10%CPU continuous (RX) with spikes up to 25-30% during TX-RX-DTMF<br>
>>useage<br>
><br>
>>That's with Top runing at a 20 sample per second rate (which eats some<br>
>> CPU<br>
>>itself mind you.<br>
><br>
>>This seems to suggest that an 'ol Pentium-3 can cut it for this app.<br>
><br>
>> Somebody please beat me with a baseball bat if I'm wrong!!<br>
> I had similar results with my P3/866, but I was hoping that a faster<br>
> processor might help to eliminate the occasional<br>
> "stumble" I've noticed with Allstar. Especially at the beginning of<br>
> telemetry or user audio, the audio will sometimes glitch.<br>
><br>
> It occasionally happens with user audio also. I've not noticed that before<br>
> when I ran an IRLP or EchoIRLP system.<br>
><br>
> I'm not sure if it's a USB-related phenomenon, since my previous systems<br>
> have used analog sound cards, rather than USB fobs.<br>
><br>
> If nodes with faster processors also have that issue, then I won't spend<br>
> any more time or energy trying to upgrade my PC, or change to simpleusb,<br>
> etc. I'll just live with it.<br>
><br>
> I figured that if the Simpleusb would be less processor-hungry, maybe that<br>
> would minimize the glitches?<br>
><br>
> 73.<br>
><br>
> Kyle<br>
> K0KN<br>
> --- Original Message --->>>also seems that the parallel port support isn't<br>
> included in<br>
> simpleusb?<br>
><br>
> Can you confirm this?<br>
> Might be really easy to get it.<br>
> I'll certainly be wanting to do this. :-)<br>
><br>
> I'm still getting free Pentium III 1U rack serves lately :-)<br>
> Which are quite sexy looking and convenient to use for this.<br>
> The used 1U Quad Xeons I purchase are going for about $850.  hihi<br>
><br>
> BTW- runing full duplex chan_usbradio on a Pentium-3 733MHz box<br>
> I see 10%CPU continuous (RX) with spikes up to 25-30% during TX-RX-DTMF<br>
> useage<br>
><br>
> That's with Top runing at a 20 sample per second rate (which eats some CPU<br>
> itself mind you.<br>
><br>
> This seems to suggest that an 'ol Pentium-3 can cut it for this app.<br>
><br>
> Somebody please beat me with a baseball bat if I'm wrong!!<br>
><br>
><br>
><br>
><br>
</div></div>> --<br>
> This message has been scanned for viruses and<br>
> dangerous content by MailScanner, and is<br>
> believed to be clean.<br>
><br>
> _______________________________________________<br>
> App_rpt-users mailing list<br>
> <a href="mailto:App_rpt-users@ohnosec.org">App_rpt-users@ohnosec.org</a><br>
> <a href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users" target="_blank">http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</a><br>
><br>
<br>
<br>
Michigan Broadband Systems Inc.<br>
"Always Connected"<br>
<br>
(734)527-7150<br>
<br>
Steve's cellphone: (734)904-1811<br>
<br>
<br>
--<br>
This message has been scanned for viruses and<br>
dangerous content by MailScanner, and is<br>
believed to be clean.<br>
<br>
_______________________________________________<br>
App_rpt-users mailing list<br>
<a href="mailto:App_rpt-users@ohnosec.org">App_rpt-users@ohnosec.org</a><br>
<a href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users" target="_blank">http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</a><br>
</blockquote></div><br></div>