Насколько я могу судить, спецификация VoiceXML не предписывает какого-либо конкретного поведения.
Я ожидаю, что интерпретатор VoiceXML должен поставить в очередь первое приглашение со всем, что имеет отношение к генерации того же вывода, как если бы оно воспроизводилось там, где он находится в очереди, включая любые нестандартные свойства, влияющие на сгенерированный вывод, такие как ttsengine
собственность. К сожалению, стандарт VoiceXML не поддерживает это понятие шага поколения . Это только поставлено в очередь или сыграно , оставляя неопределенным фактический момент, когда генерируется приглашение. Свойство audiofetchhint
влияет на то, когда платформа VoiceXML действительно извлекает аудиофайлы, но нет эквивалента для синтеза речи.
Если вы добавите fetchaudio
к элементу goto
, очередь запросов должна быть сброшена (и, следовательно, сгенерирована ) в первом документе. Обратите внимание, что это не обязательно правильный обходной путь, если вы хотите, чтобы это приглашение воспроизводилось с включенной функцией barge-in во втором вопросе.
Из спецификации:
В то время как в переходном состоянии различные запросы помещаются в очередь, либо
элемент в исполняемом содержимом или элемент <prompt>
в элементах формы. Кроме того, аудио может быть поставлено в очередь fetchaudio
приписывать. Приглашения и аудио в очереди воспроизводятся либо
- когда переводчик достигает состояния ожидания, в этот момент
воспроизводятся подсказки, и переводчик прослушивает ввод, соответствующий
одна из активных грамматик, или
- когда переводчик начинает получать
ресурс (например, документ), для которого было указано
fetchaudio
. В
в этом случае запросы помещаются в очередь до fetchaudio
завершение, а затем, если ресурс действительно должен быть выбран
(т. е. в кеше он не истек), fetchaudio
воспроизводится
пока выборка не завершится. Переводчик остается в
переходное состояние и ввод не принимается во время выборки.