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