I just switched from Slackware 12.0 to 12.1, and I’m now experiencing a format conversion problem. I’m using asterisk 1.4.20.1, Machine is 1.3ghz Duron with 256MB ram single processor.
I began using voicepulse SIP connection, and thought it might be their conversion interfaces. However using Zoom X5V SIP connection, I get the same buzziness. I recorded and played back with crystal clear performance. Only GSM “canned” audio is weird. Connection via IAX to digium (demo/test) is ALSO buzzy.
Put in some debug statements and watched the translation tables, from best I can tell, it is only on the gsm to ulaw interface that it screws up.
There are no other indicators. It doesn’t crash, hang, error… it just sounds bad.
With the change in Slackware, I’m guessing that I’m hitting a computation issue. Without knowing how the conversion data changes, I rebuilt kernel to look for RTC issues, etc and I’m not seeing any messages or indicators. I’m at a loss… Anyone heard of this before?
On specific request, I can provide a number to dial for a test.
I can use the internal file convert to make vm-intro.wav and it will play it perfectly. vm-intro.WAV (not the mswav) is buzzy and “file *” reports gsm internal format. Sox conversion, gsm to wav sounds perfect. It is simply when the gsm translation chain is built that the gsm converter produces buzzy. Slackware on a scale of 1-10 is about the least buggy implementation of anything I’ve ever dealt with. I played with compiling and not compiling using math emulation in the kernel and no difference. It reminds me of when you try to play back an a law file using ulaw. sampling or compression issues.
I can use the internal file convert to make vm-intro.wav and it will play it perfectly. vm-intro.WAV (not the mswav) is buzzy and “file *” reports gsm internal format. Sox conversion, gsm to wav sounds perfect. It is simply when the gsm translation chain is built that the gsm converter produces buzzy. Slackware on a scale of 1-10 is about the least buggy implementation of anything I’ve ever dealt with. I played with compiling and not compiling using math emulation in the kernel and no difference. It reminds me of when you try to play back an a law file using ulaw. sampling or compression issues.
Dovid, where did you find the info on “faulty version of GCC”?
I am having the same issue playing “gsm” and “WAV” (windows gsm) files on ubuntu 8.04.
I have tried the following kernels:
2.6.24-19-generic
2.6.24-18-generic
2.6.24-16-generic
I have tried the following versions of asterisk:
1.4.17
1.4.21
Did not know about the GCC issue.
Machine 1 has:
root@br:~# dpkg -l | grep -i gcc
ii gcc 4:4.2.3-1ubuntu6 The GNU C compiler
ii gcc-4.1 4.1.2-21ubuntu1 The GNU C compiler
ii gcc-4.1-base 4.1.2-21ubuntu1 The GNU Compiler Collection (base package)
ii gcc-4.2 4.2.3-2ubuntu7 The GNU C compiler
ii gcc-4.2-base 4.2.3-2ubuntu7 The GNU Compiler Collection (base package)
ii libgcc1 1:4.2.3-2ubuntu7 GCC support library
ii libgomp1 4.2.3-2ubuntu7 GCC OpenMP (GOMP) support library
Machine 2 has:
root@hh:~# dpkg -l | grep -i gcc
ii gcc 4:4.2.3-1ubuntu6 The GNU C compiler
ii gcc-3.3-base 1:3.3.6-15ubuntu6 The GNU Compiler Collection (base package)
ii gcc-4.1 4.1.2-21ubuntu1 The GNU C compiler
ii gcc-4.1-base 4.1.2-21ubuntu1 The GNU Compiler Collection (base package)
ii gcc-4.2 4.2.3-2ubuntu7 The GNU C compiler
ii gcc-4.2-base 4.2.3-2ubuntu7 The GNU Compiler Collection (base package)
ii libgcc1 1:4.2.3-2ubuntu7 GCC support library
ii libgomp1 4.2.3-2ubuntu7 GCC OpenMP (GOMP) support library
I’ll try backing out GCC and Libs to see if I can get good sound.
Can an Asterisk src wizard give an idea of how to capture a bad converted buffer to compare data generation to determine where the data is getting bugged up?
gcc 4.3 also has this problem, and it is an acknowledged defect in one of the 3rd set (-O3) of the gcc optimization engine. You can prove this to yourself by turning on the DONT_OPTIMIZE flag, which will cause the audio distortion to disappear.
If you’d like to assist the gcc team in tracking down where this issue lies, you can do so by checking out their instructions on the defect page: gcc.gnu.org/bugzilla/show_bug.cgi?id=34216