Clock precision and raw audio recording
I'm observing an effect which needs explanation. Comments from the core developers will be appreciated. The effect was tested with versions 1.4.18 and today's master, on 64-bit Debian 7 and Ubuntu 14.04. All test calls were in PCMU or PCMA. My customer requested me to build a server for call quality assurance for their telephony system. I installed FreeSWITCH and set the following in the public dialplan to record the incoming audio: <extension name="record"> <condition field="destination_number" expression="^record_(.+)$"> <action application="jitterbuffer" data="60:200:20"/> <action application="set" data="RECORD_READ_ONLY=true"/> <action application="set" data="send_silence_when_idle=400"/> <action application="set" data="record_waste_resources=true"/> <action application="answer"/> <action application="record_session" data="/var/tmp/record_$1"/> <action application="playback" data="silence_stream://-1"/> </condition> </extension> The first try was with a DigitalOcean (KVM) virtual machine. I started recording *.wav files, and sometimes there were skipped frames: 1-2 skipped frames in a 2-minute call, one in every 10-15 calls. Then I changed the configuration to write raw audio files (removed the .wav extension from the record_session argument). As a result, the recorded input audio was quite bad: lost frames every few seconds in every call. Then I made test calls within the server itself, by originating a call to its public profile and playing the test WAV audio: fs_cli -x 'originate sofia/external/record_03@111.222.222.111:5080 &playback(/var/tmp/ITU-T_P_50_BRITISH_ENGLISH.wav)' The resulting input raw audio was also choppy. The same result was on another VM on a different physical server at DigitalOcean. Then I made the same self-call tests on a Xen VM and on a baremetal ARM server, and there the recorded audio was of perfect quality. Self-calls with recording into WAV files produced audio of perfect quality. Setting RECORD_USE_THREAD=false did not change the effect. Example of choppy received audio, converted from PCMU to WAV for convenience: http://www.k-open.com/s/record_04-in.wav The source audio: http://murmur.voxserv.ch/media/ITU-T_P_50_BRITISH_ENGLISH.wav So, it looks like the clock that is available at KVM is not precise enough, but that's not my question. QUESTION: why is raw recording so much more sensitive to the clock precision? thanks, stanislav
Guess: Did you try using it with the jitter buffer enabled? The raw recording cannot pre-buffer the audio so its more likely jitter may be rendered into the file. Sometimes the gaps that are experienced are just from late packets. The WAV recordings have a more complicated process for buffering and mixing the file. On Fri, May 8, 2015 at 5:12 PM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I'm observing an effect which needs explanation. Comments from the core developers will be appreciated. The effect was tested with versions 1.4.18 and today's master, on 64-bit Debian 7 and Ubuntu 14.04. All test calls were in PCMU or PCMA.
My customer requested me to build a server for call quality assurance for their telephony system. I installed FreeSWITCH and set the following in the public dialplan to record the incoming audio:
<extension name="record"> <condition field="destination_number" expression="^record_(.+)$"> <action application="jitterbuffer" data="60:200:20"/> <action application="set" data="RECORD_READ_ONLY=true"/> <action application="set" data="send_silence_when_idle=400"/> <action application="set" data="record_waste_resources=true"/> <action application="answer"/> <action application="record_session" data="/var/tmp/record_$1"/> <action application="playback" data="silence_stream://-1"/> </condition> </extension>
The first try was with a DigitalOcean (KVM) virtual machine. I started recording *.wav files, and sometimes there were skipped frames: 1-2 skipped frames in a 2-minute call, one in every 10-15 calls.
Then I changed the configuration to write raw audio files (removed the .wav extension from the record_session argument). As a result, the recorded input audio was quite bad: lost frames every few seconds in every call.
Then I made test calls within the server itself, by originating a call to its public profile and playing the test WAV audio:
fs_cli -x 'originate sofia/external/record_03@111.222.222.111:5080 &playback(/var/tmp/ITU-T_P_50_BRITISH_ENGLISH.wav)'
The resulting input raw audio was also choppy. The same result was on another VM on a different physical server at DigitalOcean.
Then I made the same self-call tests on a Xen VM and on a baremetal ARM server, and there the recorded audio was of perfect quality.
Self-calls with recording into WAV files produced audio of perfect quality.
Setting RECORD_USE_THREAD=false did not change the effect.
Example of choppy received audio, converted from PCMU to WAV for convenience: http://www.k-open.com/s/record_04-in.wav The source audio: http://murmur.voxserv.ch/media/ITU-T_P_50_BRITISH_ENGLISH.wav
So, it looks like the clock that is available at KVM is not precise enough, but that's not my question.
QUESTION: why is raw recording so much more sensitive to the clock precision?
thanks, stanislav
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900 https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
Jitterbuffer was always enabled on the receiving side in all tests, like in the piece of config in my email. I can try disabling it. I can also try giving raw audio to playback, instead of 16-bit wav. But basically, it's not a bug, but rather a feature allowing to check the clock precision. But it will be great if we understand its nature :) On May 10, 2015 12:47 AM, "Anthony Minessale" <anthony.minessale@gmail.com> wrote:
Guess:
Did you try using it with the jitter buffer enabled? The raw recording cannot pre-buffer the audio so its more likely jitter may be rendered into the file. Sometimes the gaps that are experienced are just from late packets.
The WAV recordings have a more complicated process for buffering and mixing the file.
On Fri, May 8, 2015 at 5:12 PM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I'm observing an effect which needs explanation. Comments from the core developers will be appreciated. The effect was tested with versions 1.4.18 and today's master, on 64-bit Debian 7 and Ubuntu 14.04. All test calls were in PCMU or PCMA.
My customer requested me to build a server for call quality assurance for their telephony system. I installed FreeSWITCH and set the following in the public dialplan to record the incoming audio:
<extension name="record"> <condition field="destination_number" expression="^record_(.+)$"> <action application="jitterbuffer" data="60:200:20"/> <action application="set" data="RECORD_READ_ONLY=true"/> <action application="set" data="send_silence_when_idle=400"/> <action application="set" data="record_waste_resources=true"/> <action application="answer"/> <action application="record_session" data="/var/tmp/record_$1"/> <action application="playback" data="silence_stream://-1"/> </condition> </extension>
The first try was with a DigitalOcean (KVM) virtual machine. I started recording *.wav files, and sometimes there were skipped frames: 1-2 skipped frames in a 2-minute call, one in every 10-15 calls.
Then I changed the configuration to write raw audio files (removed the .wav extension from the record_session argument). As a result, the recorded input audio was quite bad: lost frames every few seconds in every call.
Then I made test calls within the server itself, by originating a call to its public profile and playing the test WAV audio:
fs_cli -x 'originate sofia/external/record_03@111.222.222.111:5080 &playback(/var/tmp/ITU-T_P_50_BRITISH_ENGLISH.wav)'
The resulting input raw audio was also choppy. The same result was on another VM on a different physical server at DigitalOcean.
Then I made the same self-call tests on a Xen VM and on a baremetal ARM server, and there the recorded audio was of perfect quality.
Self-calls with recording into WAV files produced audio of perfect quality.
Setting RECORD_USE_THREAD=false did not change the effect.
Example of choppy received audio, converted from PCMU to WAV for convenience: http://www.k-open.com/s/record_04-in.wav The source audio: http://murmur.voxserv.ch/media/ITU-T_P_50_BRITISH_ENGLISH.wav
So, it looks like the clock that is available at KVM is not precise enough, but that's not my question.
QUESTION: why is raw recording so much more sensitive to the clock precision?
thanks, stanislav
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>*
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900
https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I've run it on a different Xen server which is more powerful and more busy, and got also the same chopping audio in native recording. On Sat, May 9, 2015 at 12:12 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I'm observing an effect which needs explanation. Comments from the core developers will be appreciated. The effect was tested with versions 1.4.18 and today's master, on 64-bit Debian 7 and Ubuntu 14.04. All test calls were in PCMU or PCMA.
My customer requested me to build a server for call quality assurance for their telephony system. I installed FreeSWITCH and set the following in the public dialplan to record the incoming audio:
<extension name="record"> <condition field="destination_number" expression="^record_(.+)$"> <action application="jitterbuffer" data="60:200:20"/> <action application="set" data="RECORD_READ_ONLY=true"/> <action application="set" data="send_silence_when_idle=400"/> <action application="set" data="record_waste_resources=true"/> <action application="answer"/> <action application="record_session" data="/var/tmp/record_$1"/> <action application="playback" data="silence_stream://-1"/> </condition> </extension>
The first try was with a DigitalOcean (KVM) virtual machine. I started recording *.wav files, and sometimes there were skipped frames: 1-2 skipped frames in a 2-minute call, one in every 10-15 calls.
Then I changed the configuration to write raw audio files (removed the .wav extension from the record_session argument). As a result, the recorded input audio was quite bad: lost frames every few seconds in every call.
Then I made test calls within the server itself, by originating a call to its public profile and playing the test WAV audio:
fs_cli -x 'originate sofia/external/record_03@111.222.222.111:5080 &playback(/var/tmp/ITU-T_P_50_BRITISH_ENGLISH.wav)'
The resulting input raw audio was also choppy. The same result was on another VM on a different physical server at DigitalOcean.
Then I made the same self-call tests on a Xen VM and on a baremetal ARM server, and there the recorded audio was of perfect quality.
Self-calls with recording into WAV files produced audio of perfect quality.
Setting RECORD_USE_THREAD=false did not change the effect.
Example of choppy received audio, converted from PCMU to WAV for convenience: http://www.k-open.com/s/record_04-in.wav The source audio: http://murmur.voxserv.ch/media/ITU-T_P_50_BRITISH_ENGLISH.wav
So, it looks like the clock that is available at KVM is not precise enough, but that's not my question.
QUESTION: why is raw recording so much more sensitive to the clock precision?
thanks, stanislav
the problem disappears after rolling back to December code, so I opened a Jira ticket: https://freeswitch.org/jira/browse/FS-7541 On Sun, May 10, 2015 at 4:42 PM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I've run it on a different Xen server which is more powerful and more busy, and got also the same chopping audio in native recording.
On Sat, May 9, 2015 at 12:12 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I'm observing an effect which needs explanation. Comments from the core developers will be appreciated. The effect was tested with versions 1.4.18 and today's master, on 64-bit Debian 7 and Ubuntu 14.04. All test calls were in PCMU or PCMA.
My customer requested me to build a server for call quality assurance for their telephony system. I installed FreeSWITCH and set the following in the public dialplan to record the incoming audio:
<extension name="record"> <condition field="destination_number" expression="^record_(.+)$"> <action application="jitterbuffer" data="60:200:20"/> <action application="set" data="RECORD_READ_ONLY=true"/> <action application="set" data="send_silence_when_idle=400"/> <action application="set" data="record_waste_resources=true"/> <action application="answer"/> <action application="record_session" data="/var/tmp/record_$1"/> <action application="playback" data="silence_stream://-1"/> </condition> </extension>
The first try was with a DigitalOcean (KVM) virtual machine. I started recording *.wav files, and sometimes there were skipped frames: 1-2 skipped frames in a 2-minute call, one in every 10-15 calls.
Then I changed the configuration to write raw audio files (removed the .wav extension from the record_session argument). As a result, the recorded input audio was quite bad: lost frames every few seconds in every call.
Then I made test calls within the server itself, by originating a call to its public profile and playing the test WAV audio:
fs_cli -x 'originate sofia/external/record_03@111.222.222.111:5080 &playback(/var/tmp/ITU-T_P_50_BRITISH_ENGLISH.wav)'
The resulting input raw audio was also choppy. The same result was on another VM on a different physical server at DigitalOcean.
Then I made the same self-call tests on a Xen VM and on a baremetal ARM server, and there the recorded audio was of perfect quality.
Self-calls with recording into WAV files produced audio of perfect quality.
Setting RECORD_USE_THREAD=false did not change the effect.
Example of choppy received audio, converted from PCMU to WAV for convenience: http://www.k-open.com/s/record_04-in.wav The source audio: http://murmur.voxserv.ch/media/ITU-T_P_50_BRITISH_ENGLISH.wav
So, it looks like the clock that is available at KVM is not precise enough, but that's not my question.
QUESTION: why is raw recording so much more sensitive to the clock precision?
thanks, stanislav
You'll have to do a git bisect if you propose another version works better. On Sunday, May 10, 2015, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
the problem disappears after rolling back to December code, so I opened a Jira ticket: https://freeswitch.org/jira/browse/FS-7541
On Sun, May 10, 2015 at 4:42 PM, Stanislav Sinyagin <ssinyagin@gmail.com <javascript:;>> wrote:
I've run it on a different Xen server which is more powerful and more busy, and got also the same chopping audio in native recording.
On Sat, May 9, 2015 at 12:12 AM, Stanislav Sinyagin <ssinyagin@gmail.com <javascript:;>> wrote:
I'm observing an effect which needs explanation. Comments from the core developers will be appreciated. The effect was tested with versions 1.4.18 and today's master, on 64-bit Debian 7 and Ubuntu 14.04. All test calls were in PCMU or PCMA.
My customer requested me to build a server for call quality assurance for their telephony system. I installed FreeSWITCH and set the following in the public dialplan to record the incoming audio:
<extension name="record"> <condition field="destination_number" expression="^record_(.+)$"> <action application="jitterbuffer" data="60:200:20"/> <action application="set" data="RECORD_READ_ONLY=true"/> <action application="set" data="send_silence_when_idle=400"/> <action application="set" data="record_waste_resources=true"/> <action application="answer"/> <action application="record_session" data="/var/tmp/record_$1"/> <action application="playback" data="silence_stream://-1"/> </condition> </extension>
The first try was with a DigitalOcean (KVM) virtual machine. I started recording *.wav files, and sometimes there were skipped frames: 1-2 skipped frames in a 2-minute call, one in every 10-15 calls.
Then I changed the configuration to write raw audio files (removed the .wav extension from the record_session argument). As a result, the recorded input audio was quite bad: lost frames every few seconds in every call.
Then I made test calls within the server itself, by originating a call to its public profile and playing the test WAV audio:
fs_cli -x 'originate sofia/external/record_03@111.222.222.111:5080 &playback(/var/tmp/ITU-T_P_50_BRITISH_ENGLISH.wav)'
The resulting input raw audio was also choppy. The same result was on another VM on a different physical server at DigitalOcean.
Then I made the same self-call tests on a Xen VM and on a baremetal ARM server, and there the recorded audio was of perfect quality.
Self-calls with recording into WAV files produced audio of perfect quality.
Setting RECORD_USE_THREAD=false did not change the effect.
Example of choppy received audio, converted from PCMU to WAV for convenience: http://www.k-open.com/s/record_04-in.wav The source audio: http://murmur.voxserv.ch/media/ITU-T_P_50_BRITISH_ENGLISH.wav
So, it looks like the clock that is available at KVM is not precise enough, but that's not my question.
QUESTION: why is raw recording so much more sensitive to the clock precision?
thanks, stanislav
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <javascript:;> http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <javascript:;> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900 https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
participants (2)
-
Anthony Minessale
-
Stanislav Sinyagin