Extremely poor recording quality - Asterisk 11

I had a server all setup that was working pretty well, but as I was doing some security things I screwed it up and had to reinstall everything. Now call recordings are horrible and sound like this:
http://s000.tinyupload.com/download.php?file_id=58238805044662381352&t=5823880504466238135230245

I have tried it as gsm and wav, tried setting the volume only because when I downloaded it to my PC it was really hard to hear, but on playback within asterisk the volume was fine.

Opening the file in Adobe Audition allowed me to adjust the playback rate, when I played it back at 2X speed, it sounded a little better, but there was still distortion.

The call is coming in from a GSM gateway to the Asterisk 11 server which is a Dell R610 with 16GB RAM, RAID 10 HDD setup with nothing else to do other than record this call, so there shouldn’t be any load issues. When I call from a phone to a phone, the audio sounds great on the handset The recordings sounded fine before I reinstalled everything, any tips?

Here is the dialplan info (but I don’t think it is relevant, nor is it finished, only included to show nothing crazy happening)

[inbound-record]
exten => s,1,Set(TIMEOUT(digit)=5)
exten => s,n,Set(TIMEOUT(response)=15)
exten => s,n,Playback(press)
exten => s,n,Playback(digits/1)
exten => s,n,Read(ACCOUNTNUM,digits/1,i)
exten => s,n,System(/usr/bin/mkdir /var/lib/asterisk/sounds/outboundmsgs/${ACCOUNTNUM})
exten => s,n,Set(VOLUME(TX)=6)

exten => s,n,Set(VOLUME(RX)=9)
exten => s,n,Playback(vm-record-prepend)
exten => s,n,Record(/var/lib/asterisk/sounds/outboundmsgs/${ACCOUNTNUM}/tmp_greeting:wav)
exten => s,n,Wait(2)
exten => s,n,Playback(/var/lib/asterisk/sounds/outboundmsgs/${ACCOUNTNUM}/tmp_greeting)
exten => s,n,wait(2)
exten => s,n,Hangup

I have been continuing to troubleshoot this and haven’t made a lot of progress, but have learned a little. I added/ modified this in the extensions.conf file

[from-trunk]
exten => _.,1,Wait(2)
	same => n,Record(outboundmsgs/msg4:wav)
	same => n,Wait(2)
	same => n,Playback(outboundmsgs/msg4)
	same => n,wait(2)
	same => n,Hangup

[from-internal]
exten => _.,1,Wait(2)
	same => n,Record(outboundmsgs/msg4:wav)
	same => n,Wait(2)
	same => n,Playback(outboundmsgs/msg4)
	same => n,wait(2)
	same => n,Hangup

The quality when using my desk phone on the “from-internal” dialplan sounded great, but the one from my cell phone into the system using the “from-trunk” had the distortion. Calling my desk phone from the cell phone resulted in perfect quality for the call, but the system recording of that call was still bad.

Does anyone have any tips for me on what to look at next? I have upgraded sox, tried with alaw, gsm, wav, wav49, and it all sounds bad. One thing I saw in the console log is that while it is recorded in gsm / wav, the playback happens as a .slin file. The file seems to be a temp file as it isn’t ever there when I look for it, but thought I may mention it.

Further testing turned up something interesting. I was using a 2 slot VS-GW1202 with my asterisk configuration and all was working great, so I thought I would step it up to the 11 slot VS-GW2120, but that was when it all broke. (I also reinstalled Asterisk, so I didn’t realize that it was potentially a problem somewhere else.)

I set it back up with the old one to confirm, and the recorded audio is great. The sound quality on the actual call is fine, which is really confusing to me. How can my call sound great, but the recording not, but have the problem be my SIP trunk device?

Any tips on what to look at?

Solution posted here: Recording quality different from on call quality

I worked till midnight last night with the tech support from OpenVox and we finally found the issue. There is something funny with their Ethernet ports on the new box where port 1 can only see slot 1, to see the others I plugged into port 2, but had left port 1 also plugged in - which effectively gave it 2 routes with the same IP…

That would be why it was recording 50% slower, because in a round robin of receiving it would take a packet from port 1, then port 2, then port 1 again, but only 1 of them would have data. Unplugging one of them resolved all the issues.