Chanspy poor audio quality

I’m using Asterisk 1.8 with a fairly standard setup. I’m able to successfully spy on calls using Chanspy but the audio is very poor. It cuts in and out and the conversation is barely understandable. I looked around on google and this seems to be common problem in older versions. Has anybody else experienced this?

Here is a code snippet of my dialplan

same => 555,1,NoOp(Spying on 'Ben') same => n,Set(VOLUME(TX)=8) same => n,Set(VOLUME(RX)=7) same => n,ChanSpy(SIP/benhalberg,q) same => n,Hangup()

Yeah I’m getting exactly the same thing.

I migrated from asterisk 1.4.6 to 1.8.6 and this is the only issue i seem to be having.

What timing source are you using? What happens if you use the latest 1.8.x version?

Sorry what do you mean by timing source? This quality thing is really starting to bug me.

wiki.asterisk.org/wiki/display/ … nterfaces#

Oh I see. I’m just using the defaults, whatever module that happens to be. Do timing issues apply to SIP? The issues in the article seem to reference mostly DAHDI. Thanks for the help

Timing sources generally become an issue when not using Dahdi. They affect conferencing, tones, announcements and music on hold. I’m presuming that spying has some aspects of a conference. As you are not using the latest versions, you may need dahdi loaded to provide adequate timing sources, as early versions of timerfd have problems.

I can see that none of my Dahdi timing modules are loaded. In fact, looks like nothing dahdi is loaded (I think I did this purposely during install). Now all of the modules have XXX next to them.

I’m also having this problem.
It’s not only present on chanspy but also on call recordings.
The calls between the parties are crystal clear
[LAN alaw <-> g729 WAN SIP TRUNK]
But in the call recording/chan spy the WAN party sound like mr roboto.
Changed everything that could have been changed and this still happens.
The strangest thing is that it happens only when certain number ranges are dialed.

Also recently discovered that when I’m recording, this is happening:
DEBUG[19081] audiohook.c: Read factory 0xae173e0 and write factory 0xae17e18 both fail to provide 160 samples
DEBUG[19081] audiohook.c: Failed to get 160 samples from write factory 0xae17e18
DEBUG[19081] audiohook.c: Read factory 0xae173e0 and write factory 0xae17e18 both fail to provide 160 samples
DEBUG[19081] audiohook.c: Failed to get 160 samples from write factory 0xae17e18

This appears to have no effect on the recording quality.
The only downside is the huge debug log (that i usually keep deactivated).

Any ideas?

Thanks

PS
Tried 3 different timing modules and got no improvement (pthread, dahdi and timerfd).