Re: Suggested change to <audio/>

At 11:37 AM -0500 4/27/06, Shane Smith wrote:
>Hey Folks,
>
>One of the best features of audio is the ability to play backup tts
>should the audio source be unavailable.  Currently though, <audio/>
>requires either the src or expr attributes to be listed, or a badfetch
>is tossed.  Well, I've come upon a scenario where I wouldn't
>necessarily want to list either, and use the backup tts feature in a
>way that wasn't anticipated, but could be very useful.
>
>For example, let's say I'm playing an account number to the caller:
>   <audio expr="AudioDirectory+'1.wav'">1</audio>
>   <audio expr="AudioDirectory+'2.wav'">2</audio>
>   <audio expr="AudioDirectory+'3.wav'">3</audio>
>   <audio expr="AudioDirectory+'4.wav'">4</audio>
>   <audio expr="AudioDirectory+'5.wav'">5</audio>
>   <audio expr="AudioDirectory+'6.wav'">6</audio>
>
>I'm not going to prerecord every possible number, so I play audio one
>digit at a time.  But, if for any reason one or more of them is
>unavailable, I would rather the whole thing be read back as TTS.   The
>above code sounds horrible as backup tts, and I do not really have
>ssml control over it.
>
>What I would like to see is this:
>
><audio>
>   <audio expr="AudioDirectory+'1.wav'/>
>   <audio expr="AudioDirectory+'2.wav'/>
>   <audio expr="AudioDirectory+'3.wav'/>
>   <audio expr="AudioDirectory+'4.wav'/>
>   <audio expr="AudioDirectory+'5.wav'/>
>   <audio expr="AudioDirectory+'6.wav'/>
>   <prosody rate="-10%">
>   <say-as interpret-as="digits">123456</say-as>
>   </prosody>
></audio>
>
>This (or something similar) would allow you to chain a bunch of audio
>prompts together, but if any of them fail, have a single backup tts
>prompt replaced for all of them.  In my head, if all numbers wav files
>were unavailable, or even if just 5.wav were unavailable, none of them
>would play, and the ssml'ed TTS would play instead.
>
>Thoughts?

Option 1:

have you looked at using a SMIL[1] as the @src value?

I think you would have to do things with test variables to force
it to fail atomically if any of the embedded <seq> constituents
were unavailable, but the concatenation is there.

Option 2:

Alternatively, review DISelect when it re-emerges in its
next incarnation [2] and consider how you would fold this into
VoiceXML 3.0.

Option 3:

Program the sequences-and-options logic in SCXML [3].
You may get this in VoiceXML 3.0 even if you don't push for it.

Al

[1] http://www.w3.org/TR/2005/REC-SMIL2-20051213/

[2] (some version dated after today of) http://www.w3.org/TR/cselection/

[3] http://www.w3.org/TR/2006/WD-scxml-20060124/

Al

>
>Thanks,
>Shane Smith