[App_rpt-users] First experience with ACID app_rpt & usbradio audio popping problem.

[Steve Gladden]

We've also had 5+ years of great success with asterisk..
I've  seen asterisk do a LOT of DSP + Transcoding on one a Pentium400Mhz 
CPU.
And I've done some DTMF + packet radio DSP on old Pentium 100Mhz and 486 
66Mhz Systems.
Which is why I'm not at all sold on the issues with audio being not 
enough CPU on a 1.1Ghz Duron. :-)
I'm willing to listen & learn..
I'm in the processof trying to abply Dave's fixes (new kernel with 
precision timer set to 1000Hz) and ztdumyc+usbradio.c hacks and compare 
that as well..

I'm struggling to being up a working kernel on my first system to test 
with a fresh compiled kernel of my own..

Meanwhile I'm going to try this on a 3Ghz all Intel much faster and see 
if the radio drop outs are indeed gone or if they're all still there
and if in the same way or different...

David:  I'm still working on trying your fixes..
BTW P3 450Mhz is working *almost perfect* just by turning off that stat 
post thing.. :-)
It's good enough as is to use as a home/test node but not on a 
production/remote system.
I'm #2586 and on most of the time :-)
Feel free to give us a shout!

And thanks everyone here for all of your help & suggestions..

I can appreciate that in general that everyone out here who has a 
working system is using much faster system than I have reported to be 
giving me issues..
And I will be movingto/testing on much faster new systems as well...
I'm just the kind of person who has to know why it's not working 
properly on a Pentium3 /450 for the fun of it.
So far I've not been able to conclude on my own that a 300 or 400Mhz 
Pentium2/3 system can't handle this due to not enough CPU.
I think I've done some reasonable test thus far to determine that the 
CPU is not being even anyhwere remotely close to being maxed out..

The behavior I'm seeing it such that I first suspect faulty programming 
(that can be fixed) or improper/ non optimal use of precision timer.
Or the way dsp work is being scheduled/prioritized along with the timer 
interrupt..

In other words it may be written is such a way that it happens to work 
better on high speed systems.. but when looking at it closely it's not 
failing
because the CPU is actually maxed out... it's failng because it was 
written in such a way that a certain amount of work is expected to get 
done within
one timer routine..

Or the task is not written in a guaranteed to get done without being 
interrupted by something that should technically could be held off to 
make the audio stream
the top priority or 'non interruptable' during it's most critical thing 
it does ;-)

I'm not an experienced programmer with this stuff but I'd like to learn 
and help out when I am able to!
This is a big learning experience for me as far as the opportunity to 
learn how to do some programming/tweaking in C goes.

Thanks very much for your help & your patience and your listening :-)

Steve


















David McGough wrote:
>
> On Wed, 18 Nov 2009, Jacob Suter wrote:
>
> <snip>
>   
>> You're currently describing why I don't use Asterisk for my PBX - it seems
>> to desire an outrageous amount of dedicated resources to make work
>> consistently.  I find FreeSwitch seems to work 99% better in these
>> situations, but FreeSwitch's repeater control module (fs_rpt) is still
>> incomplete and theres no Echolink or IRLP linking options (yet)
>>
>> >From my own tests I can say Asterisk isn't as much CPU hungry as it is
>> "consistent performance hungry".  Your old P3 is likely fast enough to
>> handle the job, but when things like disk I/O occur (IDE and SATA drives
>> *LOVE* 'eating' your machine's performance up during I/O) it just can't keep
>> up for a few milliseconds, and asterisk doesn't recover well from the
>> situation.
>>
>> People tend to throw a lot of CPU at it, because CPU is cheap and easy, and
>> end up having the same problems.  I'm fairly certain $25 worth of surplus
>> SCSI controller, cable, and disk off ebay would likely cure the largest
>> problems you're seeing.
>>
>> Also, while you're Ebaying, treat yourself to a nice Intel 10/100 adapter.
>> I buy them surplus by the 10 pack, myself.  Junk Ethernet adapters (Realtek,
>> VIA, etc) are a performance-eater under any circumstance.
>>
>> Good Luck!
>>
>> JS
>>
>>     
>
>
> Hi Jacob,
>
> Interesting info about freeswitch. I had heard it was out there, but
> haven't looked at it. I've had excellent results with asterisk as a PBX
> over the last 6 years or so. There were some rough edges to start with, as
> expected with any software. We now run/use several asterisk boxes at
> different locations for my business; mainly connected to T1's and
> providing VoIP gateways, etc. And, we have a few FXS lines here and there
> for analog connections to fax machines, etc. All of these boxes are in the
> 1GHz CPU range, AMD CPU, and cheap ethernet. Aside from somewhat weak
> software echo cancellation, they really work great. We went ahead and
> deployed hardware/DSP echo cancellation where needed, and that issue was
> resolved, too.
>
> Anyway, for us, asterisk is very much a success story....But, we're not 
> trying to "reinvent" the phone company, either!
>
> 73, David kb4fxc
>
>
>
>   
>> _______________________________________________
>> App_rpt-users mailing list
>> App_rpt-users at qrvc.com
>> http://qrvc.com/mailman/listinfo/app_rpt-users
>>
>>     
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at qrvc.com
> http://qrvc.com/mailman/listinfo/app_rpt-users
>
>   


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.