[Home]

Summary:ASTERISK-01507: PlayBack and Background applications garble their sounds
Reporter:williamd (williamd)Labels:
Date Opened:2004-04-29 19:45:09Date Closed:2011-06-07 14:04:43
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) etc.zip
Description:No errors are reported by * or zaptel installations (see Additional Information). Have setup various SIP phones to make and receive calls through the * box without a problem.

BUT for some reason the PlayBack and Background applications garble their sound e.g. when you set up a voice menu or the echo test.

What is being said is JUST legible. But it is like listening to voice over a connection that is losing two thirds the packets - your mind has to fill in the missing bits.

We were hopeful this would be a problem caused by our .conf files, but the problem occurs with the sample .conf file set too. Someone told us that X can cause this problem, but of course that would be just TOO easy.

We've tried just about every bit of advice we've come across - for example, doing an export=LD_ASSUME_KERNEL=2.4.1 before running * - but nothing has solved it.

We are engineers so I hope that we are reasonably good at covering all bases. But its been a few days of banging our head against a brick wall.

A true bug indeed :) Help.

****** ADDITIONAL INFORMATION ******

LOGIN: Qualified * developers free to login as root to experience the bug and play with installation and code. Please ask Dominic (dwilliams@airdocs//nospam//.com) for passwd and IP of machine.

MACHINE
Dell 1650 2 processor blade (1 CPU installed), Perc/3i RAID, 500MB RAM. X100P card installed.

SOFTWARE
RHEL v3 with all latest rpms.

CVS
Latest * downloaded 6pm 30th April, latest pri, zaptel downloaded 3 days earlier.
Comments:By: williamd (williamd) 2004-04-29 19:53:31

I should have said latest CVS downloaded 6pm 29th April (my timezone is 6hrs ahead, so I got the date was wrong).
By: Brian West (bkw918) 2004-04-29 19:55:50

I'm using latest cvs as of a few min ago and mine are fine.  Could this be a hardware problem?
By: Mark Spencer (markster) 2004-04-29 20:24:24

This is almost certainly not a bug but either bad hardware or a configuration issue of some sort.  Bogosity meter runs extremely high here.  Try unloading the zaptel and x100p drivers and try running asterisk and see if the problem persists.
By: twisted (twisted) 2004-04-29 20:39:25

I cannot reproduce this with latest cvs either...
By: Brian West (bkw918) 2004-04-29 20:46:10

Also DO NOT RUN X, you asked about this today in #asterisk-bugs and we all told you it had to be a hardware related issue and asked if you were running X you never responded.

bkw
By: Brian West (bkw918) 2004-04-30 11:07:22

You're going to have to respond faster to these Major bugs as they are what is keeping the 1.0-RC1 from taking place.  Please try to respond ASAP.

bkw
By: williamd (williamd) 2004-04-30 12:26:13

Hi guys, I hear what you were saying and have working on further ideas.

I should clarify that this problem does not have straightfoward solution. IMHO this has nothing to do with X (running at level 3 makes no difference), the .conf files (the problem persists with the * sample files) and so on.

The machine is a bog standard Dell 1650 blade running freshly installed RHEL v3 with the latest rpms.

It contains a new X100P card. I got the latest zaptel and * and built them again only an hour ago.

Like Mark said this must have something to do with my hardware - or alternatively how */zaptel interacts with this particular combination of hardware and OS.

Here are some further ideas/ notes:

1/ cat /proc/interrupts shows x100p has 5 to itself and takes about 1000 a second. zttools it shows the device as X101P and Current Alarms: Red Alarm (is this bad?). However the zaptel drivers/modules never report any errors.

2/ I am have Perc 3/Di RAID in the server which has its own processor and clock. Could aacraid be giving * a timer problem somehow? // I'm thinking that a timer is needed to playback sounds.

3/ I am running an SMP kernel although I only have a single CPU installed. Could this be giving * a timer problem somehow?

4/ When * was spawning mpg123 briefly it was going busy. I removed the mpg123 rpm from my system (I got it from fresh rpms not Red Hat) but * still has the same problem. Maybe the mpg123 problem hints at a shared cause.

5/ When I dial my echo test extension, although the Playback demo-echotest speech sounds garbled, I can hear my own echo / speech fine

6/ Running out of ideas.. maybe the PSTN cable needs to be in the back of the X101P card?? :}
By: williamd (williamd) 2004-04-30 12:28:33

I also should have said that I tried zaptel stop, and then running * again as Mark suggested. * didn't like that, and various problems occurred [will report further if interesting]
By: Brian West (bkw918) 2004-04-30 12:44:48

do mpg123 --help you might find that its accually mpg321 with a symlink.  

Also mpg123 0.59r is known to work perfectly.  And yes X can cause a problem.

Red Alarm means you don't have the line pluged in or in the correct slot.

show me 'lsmod'

bkw
By: williamd (williamd) 2004-04-30 13:06:45

More ideas / info

7/ I've put the default run level to 3 and rebooted to get X out of the equation (no change)

8/ I've noticed that if I run top the CPU states line reports irq running at about 17%

9/ lsmod shows:
lp
parport
autofs
e1000
wcusb (unused)
wcfxo
zaptel [wcusb wcfxo]
floppy
sg
microcode
keybdev
mousedev
hid (unused)
input
usb-ohci (unused)
usbcore [wcusb hid usb-ohci]
ext3
jbd
aacraid
sd_mod
scsi_mod [sg aacraid sd_mod]
// some column 4 items omitted for brevity

Re: mpg321.. I was aware of the problem with mpg321. My RHEL didn't have it on originally anyway, so I went and obtained an rpm for mpg123 (from fresh rpms website, so may not have been suitable for RHEL). This has been removed from the system to eliminate it, but I will get the proper mpg123 and report back asap
By: williamd (williamd) 2004-04-30 13:44:24

10/ My build of mpg123 0.59r behaves itself when called by *. However the moh you hear is garbled in much the same way (as with Playback and Background, you can just hear what is being said, but the effect is as if the sound is being transmitted across a very lossy network.. or shaky, like there is a timing issue).

***Would this not indicate that, since normal speech is fine, that the problem is occurring in the code that mixes these sounds into the main channel??***

This really seems like a timing issue - after all you need a Zaptel timer to run the conferencing system, which also involves mixing?
By: williamd (williamd) 2004-04-30 13:58:00

Does anyone have a way of finding out (a) which timer is being used by the mixing system and (b) whether it is working ok?

Many thanks, Dominic
By: Brian West (bkw918) 2004-04-30 14:15:00

cat /proc/interrupts

include that
By: williamd (williamd) 2004-04-30 14:30:07

cat /proc/interrupts
0: 382618 XT-PIC timer
1:   2907 XT-PIC keyboard
2:      0 XT-PIC cascade
3:  73425 XT-PIC aacraid
5:3279410 XT-PIC wcfxo
7: 129143 XT-PIC eth0
8:      1 XT-PIC rtc
11:     0 XT-PIC usb-ohci
12: 31087 XT-PIC PS/2 Mouse
14:  4485 XT-PIC ide0
NMI:    1
ERR:  135
By: twisted (twisted) 2004-04-30 14:39:15

Those Errors kinda strike me as odd... I have zero sound problems, but then again, i have zero interrupt errors... not to mention, my t100p is sharing the irq with another device..

          CPU0
 0:   53565359          XT-PIC  timer
 1:        832          XT-PIC  keyboard
 2:          0          XT-PIC  cascade
 5:          0          XT-PIC  ehci_hcd
 8:          1          XT-PIC  rtc
 9:          0          XT-PIC  acpi
10:  535605868          XT-PIC  ohci1394, usb-uhci, t1xxp
11:   19500793          XT-PIC  viafb, usb-uhci, eth0
12:   70463182          XT-PIC  via82cxxx, usb-uhci
14:    1102663          XT-PIC  ide0
15:          5          XT-PIC  ide1
NMI:          0
LOC:          0
ERR:          0
MIS:          0

edited on: 04-30-04 13:37
By: Brian West (bkw918) 2004-04-30 14:40:29

This has to be a hardware issue ... hrm..
By: twisted (twisted) 2004-04-30 14:41:47

try rmmod'ing all the modules for zaptel and install them manually.  wcusb shouldn't really be loaded...  only modprobe wcfxo, it should bring zaptel with it.  seems to me like a hardware problem..
By: williamd (williamd) 2004-04-30 14:59:51

rmmod'ed all modules and modprobe'ed wcfxo.

All right messages (no errors, "Found a Wildcard" etc) but playback still garbled.

NMI: 1 and ERR: 135 unchanged after the garbled sound too...

Nb. am I right in understanding that you only need the timer for mixing, which is why speech works ok?
By: Mark Spencer (markster) 2004-04-30 20:44:30

Out of curiosity does this problem occur with both stable and head?
By: Mark Spencer (markster) 2004-05-01 19:47:02

I hate to keep bugging you, but you have *got* to respond faster if you want us to keep these bugs open since they are bugs that we are unable to duplicate and yet they are holding up the asterisk-1.0-RC1 and 1.1-RC1 releases.
By: Mark Spencer (markster) 2004-05-01 22:00:04

I've also added a new tool to zaptel called zttest.  That tool should be able to verify if your zaptel infrastructure is running smoothly.
By: williamd (williamd) 2004-05-03 08:20:36

Hi Mark, I'm back in the office atm. It is a bank holiday over here in the UK and I'll be in and out but I will try to answer your questions as quickly as possible.

Re: stable/head. The problem occurs with both stable and head (at least with asterisk - I don't know if you have equivalent defines for zaptel and libpri?).

Re: zttest. I dunno how to interpret the results but here goes. After 50 iterations the best was 93% and the worst 75%. The majority of results seemed to be coming in at 81% +/- 3%.

Q: - how come speech isn't screwed by the timer (if it is that) but the blending in of background sounds is?
By: Mark Spencer (markster) 2004-05-03 09:13:48

The background is timed off a zaptel timer.  The test results should run at no worse than 99% ever, so anything under that represents serious issues at the hardware level (i.e. interrupts not being received).  This is not a "bug" but some sort of hardware level issue.  Please contact Digium technical support and see if they can help you get through this.