CallXML 3.0 Development Guide

| TOC

Appendix A: Audio Files & CallXML

Using TTS is fine and dandy when you are demoing an application, but eventually, we will want to add recorded audio to our application for a more user-friendly appeal to your callers.This guide will serve as your Holy Grail when it comes to questions that you might have about recording audio and using professional audio prompts in your CallXML applications.

Audio Formats

The supported audio formats for the CallXML markup are as follows:

8bit 8kHz mulaw mono .wav files
8bit 8kHz mulaw mono . vox files

If you are developing both CallXML and VoiceXML applications, and would like to keep your audio prompts as 'universal' as possible, it is recommended that you stick with the 8bit/8kHz wav format, which is supported on both platforms.

Alternate Text-to-Speech

The implementation of CallXML 2.0+ has added support for alternate Text To Speech in your application in the event that your audio files return a '404' error, and cannot be found. The new 'say' attribute has been added to the following elements to allow for this functionality:

<playaudio>
<inputaudio>
<inputdigits>
<menu>
* <prompt>

* = While there is no specific 'text' attribute mapped to this element, <prompt> will use the 'value' as a literal string of backup TTS to generate when the audio file cannot be found, .

An example of backup TTS generation in action would look like this:



...

  <do>

    <playaudio value="BogusFile.wav" say="here is some backup TTS"/>

  </bdo>

...

Audio Terminology

Amplitude - is basically the "volume" or loudness of a moment of audio.

Sample - is a recording of a "moment in time" of audio. Basically, each sample records the amplitude or volume of the audio at a moment in time. Audio recordings are made up of thousands and thousands of individual samples, each of which indicates the amplitude of the audio at that moment.

Sample rate - how fast audio is recorded or "sampled". An 8khz sample rate means 8,000 pieces or moments of audio amplitude information are recorded per second. 16khz means 16,000 per second.

Sample bits - how much information is in each sample. Typically, each sample has 8 or 16 bits of information.

Peak Amplitude - is the "peak" or loudest (or highest) volume/amplitude encountered during all the samples in an audio recording.

RMS Amplitude - is the average volume or amplitude in an audio recording.

CODEC or Encoding - indicates how the audio samples are represented in the sample bits, and/or how they are "compressed" to fit more information into the sample bits. For example, PCM encoding saves the amplitude values into the sample bits without any compression. uLaw or aLaw effectively store 16 bits of sample information into just 8 bits.
GSM, MP3, RealAudio, and other types of encoding store even more information into less bits.

Some Facts

All telephony uses 8khz sampling. 8000 samples per second is a universal constant in telephony.

Traditional telephony uses 8 bit samples with either uLaw or aLaw encoding. VOIP telephony commonly uses uLaw (also known as G.711), aLaw, GSM, or other encoding/compression such as G.723.1, G.729 to squeeze more audio into less bandwidth. FYI, future VOIP telephony may support "wideband" encoding that uses higher sample rates and encoding
formats to deliver the equivalent of Hi-Fi for telephony. We're already seeing "Hi Fi" type telephony audio on some high-end video conferencing solutions. However, to get back to reality and today, it's all 8khz ubit uLaw.

If you look at a microphone cable, you'll notice it has two wires. If you look at a speaker cable, you'll notice it also has two wires. Now look at a phone cable - phones have both a microphone and a speaker, but phone cables can have just two wires per phone line, and it works fine. But wait a minute? If every telephone has a microphone (2 wires) and a speaker (2 wires), that takes 4 wires. So how does it work with two? Simply put, phones combine or "mix" the input and output audio
onto one set of wires.

Because telephones combine input and output audio, telephones can and do create echo - just like what happens when you put a microphone too close to a speaker. Almost every call we make has echo; however, the human mind automatically "filters out" an echo that occurs less than 200ms or so from when we said something, and most telephony echoes come
back in under 200ms. So, our perception is that we don't here the echo. However, sometimes factors can combine to make the echo take more than 200ms to get back to us, and we start to here it. Anything that introduces latency or delay on a phone call can make the echo delay long enough to "hear it", including: calls on cell phones, which have more latency and thus more echo delay; calls to the other side of the world, where the audio takes longer to get there, and thus the echo takes
longer to get back; calls via satelite, etc.

Because echo can take more than 200ms on some types of telephony in some situations, telephony devices often have "echo cancelers". Echo cancelers are filters that attempt to "remove" the echo audio before the
audio is sent to our ears, (or to the recognition engines...more on that below).

Some Problems

When recording audio for use in telephony / IVR systems, the audio ultimately must be converted from bit rates other than 8khz and audio encodings other than 8bit uLaw - because 8bit ulaw is the only type of audio you can send over the phone network (at least here in the US). This conversion from higher bit rates and alternate encoding types can
occur in the IVR platform, but it's best for the conversion to be done in advance by IVR developers or prompt studios.

There are many audio tools out there that can convert bit rates and audio encoding, but few which do these conversions well.

Often after conversion, the resulting audio may sound too low; that is, the RMS amplitude - the average volume - is lower than callers are comfortable with. To fix this, many audio tools offer a "gain control" feature to boost the volume of audio.

Sometimes after conversion, the resulting audio may be TOO LOUD, that is, the RMS amplitude - the average volume - is higher than callers are comfortable with. Again, gain control can be used to fix these problems.

Sometimes, audio has POPS and CLICKS in it. These can result from a few things - bad recording, bad gain, or bad samples. If the audio was recorded with a microphone or telephone that is cheap or glitchy, those microphones and telephones can introduce pops and clicks. However, often, pops and clicks result from gain (ie volume increase) being "turned up" too high. When gain is too high, audio can "clip" as the peak amplitude in an audio recording exceeds the maximum volume that can
be used with the selected encoding format.

Sometimes, audio is so loud that the voice recognition engine can "hear" it. What the reco engine actually is hearing is the ECHO from an audio prompt. While our mind filters out echo under 200ms, the reco engine does not. The louder a prompt. the louder its echo will be. The echo can become so loud that the reco engine mistakes it as being a command or question spoken by the caller, and that's bad for your user-experience.

Some Solutions

Audio should always be converted to 8khz uLaw for use in the Voxeo platform... because one way or another, it's going to end up that way.

Programs like cooledit (now Audio Audition), Goldwave, and SoundForge can all be used to convert audio formats. However, SoundForge is the best - and also the most expensive at $399

While these programs can be used to convert audio, getting the right combination of audio sample rate, encoding, peak amplitude, and RMS amplitude in order to make prompts comfortable for users - but not so loud that the audio has pops or clicks or the reco engines hear echoes from the prompts - can be quite challenging. For these reasons, Voxeo always recommends that our customers use the services of professional IVR prompt recording companies like The Great Voice Co. to record their
prompts. In short, it seems like it should be easy to record your own high-quality audio prompts; but it is most assuredly not.

Ignoring Our Advice -- Recording your own prompts

If you don't plan on mixing and editing the prompts they record, it's best to just record at 8khz/16bit and then save or convert to 8khz/8bit-ulaw.

If you plan on mixing and editing prompts they record, it's best to record at 48Khz/16bit, and not 44Khz, (the down-sample to 8Khz works much better when you are dealing with something that is a multiple of 8k), and then save or convert to 8khz/8bit-ulaw when you are done mixing and editing their prompts.

Most definitely use the gain control tools in your audio software to adjust the RMS amplitude and peak amplitude of your audio recordings so that audio is loud enough to be heard by customers; but not so loud
that prompt echoes will be heard by the reco engine; and not so loud that pops and clicks are heard as a result of clipping.

Voxeo Audio Library

Voxeo has anticipated your audio needs, and has a bountiful selection of professional prerecorded audio files available for download, free of charge. These audio files are in 8,000 Hz, 8 bit, MuLaw .wav format, which you can download right here!

The recorded prompts cover the following:

airport codes
alphabet
common Navigation
credit card
currency
dtmf tones
dates and times
greeting files
math
numbers
PIN
common prepositions
press digits
telephone
voicemail prompts

Audio Tools

If you are not certain how to go about getting your files in the proper format, Windows users can use the Sound Recorder to check the file and make changes to it; simply open the file, then select "File" "Save as"..., press the "Change..." button, and change the attributes to "8,000 Hz, 8 Bit, Mono" and you should be ready to launch. However, for the folks that prefer more powerful sound editing software, there are a number of freeware programs that can fit the bill. A listing, (by no means complete), of some good offerings are as follows:

Audio Links

If you are looking for professional voice talent for your application, and you don't see files that meet your specific needs in our download library, you would do well to contact:

Recording Audio

When recording audio with CallXML, keep in mind that before we attempt any kind of playback to the caller, we must first store the recording on a webserver via FTP:



<recordaudio

      value="ftp://MyPassword:MyUserName@Myserver.com/MyMsgTitle.wav"

      format="audio/wav" termdigits="all" maxtime="10s" maxsilence="2s"

      beep="true">

Afetr which, we can reference the audio file as a URL within the <playaudio> element:



<playaudio value="http://MyServer.com/MyMsgTitle.wav"/>

If playback isn't a concern, then you can also send the recorded audio as an email attachment. In the email itself, we can specify a number of parameters to properly format the email message that gets sent out, as illustrated in the below snippet:



 <recordaudio value="mailto:hasselhoff@baywatch.com?subject=

        Youre fired&fromname=

        The Network&fromaddress=

        muckitymucks@TheNetwork.com&body=

        Sorry dave. Just found out that you have no appreciable talent.

        The enclosed recording details the fact that Baywatch On The Moon

        is cancelled"/>

ANNOTATIONS: EXISTING POSTS

tjgillies

8/31/2007 4:39 PM (EDT)

Audacity is also a good sound program (free)

jpw

4/15/2008 3:41 PM (EDT)

have you documented anywhere where to PUT the audio files that <prompt> is going to play?

MattHenry

4/15/2008 3:47 PM (EDT)

JP,

Sorry if this wasn't clear from reading the docs; the audio files referenced via <prompt> should sit in the same directory as the CallXML file that references them. It wouldnt make much sense if the server returned a 404 and the TTS fallback had to try and render something like this:

<prompt value="http://www.myserver.com/myIVR/myaudio/hello world.wav"/>

~Matt

SSA_NCH

1/27/2010 4:58 PM (EST)

If my app is using TTS (e.g., the "say" element), is there a way to disable the .WAV fetch attempts? Right now my webserver log is littered with '404' errors for all of the TTS my app does. Thanks! -Eric

jdyer

1/27/2010 5:20 PM (EST)

Hello,

I am afraid the way the prompt CallXML works with backup TTS is to look for the 404, at which time it reverts to backup TTS. If you are looking to avoid the fetch you may want to try the <say> element (http://docs.voxeo.com/callxml/3.0/say.htm), which does not do the preliminary fetch. I do hope this helps, and if there are any other questions please let us know!

Regards,

John Dyer
Customer Engineer
Voxeo Support

Cache Control

| TOC

| B: Outbound Dialing