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!!
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.
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
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.
Why not run ntpd and keep your clock in sync all the time instead of once an hour :) Jim, K6JWN On Thu, Feb 17, 2011 at 01:09:17AM -0600, Chuck Henderson <rpt2@chuck.midlandsnetworking.com> said:
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
Hi Chuck.. My box (pretty much a fresh ACID install) does not even have NTPD running on it. What I did try was running the heck out of ntpdate which has absolutely no effect whatsoever on the audio as it does it's thing syncing the clock. I've done a LOT of other 'similar' tests like this over the past year trying to find something that influences the behavior or induces it to occur. While I was at it I also ran <hwclock --systohc> just for kicks. Again about anything I can think of does not cause the issue to surface.. It just does it on it's own seemingly randomly. In it's little subtle irritating way :-) And just for convenience... a video from Nov 14 2009. Radio Key command listening to PL and the issue. :-) http://www.youtube.com/watch?v=lqYwhtuVLDs -Steve
Why not run ntpd and keep your clock in sync all the time instead of once an hour :)
Jim, K6JWN
On Thu, Feb 17, 2011 at 01:09:17AM -0600, Chuck Henderson <rpt2@chuck.midlandsnetworking.com> said:
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
-- 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.
What I did try was running the heck out of ntpdate which has absolutely no effect whatsoever on the audio as it does it's thing syncing the clock.
I have three D510mo boxes with URIs and, on one of them, ntpdate usually kills the sound fob altogether (blinking light stops) On the other two boxes, it works without a problem. Go figure. Ken
Could be a clue! I also have one out of 4 D510MO boards that will not run the allstarlink software. For all other uses the odd board works fine. I can't find any difference, all boards came from same production batch, almost sequential serial numbers. There must be some tiny tolerance issue but I am clueless to figure it out. I just found a different purpose for that board. On Thu, Feb 17, 2011 at 4:49 PM, Ken <ke2n@cs.com> wrote:
What I did try was running the heck out of ntpdate which has absolutely no effect whatsoever on the audio as it does it's thing syncing the clock.
I have three D510mo boxes with URIs and, on one of them, ntpdate usually kills the sound fob altogether (blinking light stops) On the other two boxes, it works without a problem. Go figure. Ken
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
participants (5)
-
Chuck Henderson -
James Nessen -
K&R Yoksh -
Ken -
Steve Gladden