Voicexml how many words in grammar -

i want have dynamic grammar in voicexml file (read single products , create grammar php)

my question is, if there advice or experience how many words should writte source read products. don't know structure or pronunciation of words, let's

a) words rather different each other b) words rather have same structre or pronunciation c) mix of a) , b)

thanks in advance

i'm assuming mean srgs grammars when indicate dynamic grammar voicexml.

unfortunately, you're going have performance testing under reasonable load know sure. i've transmitted 1m+ grammars under conditions. i've done 10,000 name lists. i've come across platforms can utilize few dozen entries.

the speech recognition (asr) , voicexml platform going have significant impact on results. and, number of concurrent recognitions grammar relevant along overall recognition load.

the factors mention have impact on recognition performance , cpu load, i've typically found size of grammar , length/variability of entries matter more. example, yes/no grammars typically have higher cpu load complex menu grammars (short phrases tend require more passes , leave open larger number of possibilities when processing). i've seen horrible numbers wide ranging digit grammars (9-31 digit grammars). sounds short , difficult disambiguate. variability in components, again, creates large number of paths have continuously checked solution. menu or natural speaking phrases have longer words sound different many paths can excluded.

some tips:

most enterprise class asr systems support cache. if can identify grammars url parameters , set http header information asr needs (don't assume follow standards), may see significant performance boost.

prompts can hide grammar loading/compiling phases. if have relatively long prompt people tend barge in, you'll find can hide large grammar fetches. again, not platforms job of processing these tasks in parallel. note, asr engines can collect audio , perform end-pointing, while still fetching , compiling grammar. buys more time, you'll see impact in longer latencies.

most asr engines provide tools let analyze grammar sample audio. tools give cpu resource indicators. i've found can calculate/predict overall performance due complexities around recognition concurrency, can give comparative impact other grammars. have yet find engine makes easy track grammar processing times, can difficult guess concurrency challenges. in cases, large scale testing has been necessary.

after grammar load/compile times, recognition concurrency significant performance impact. i've seen few applications have highly complex grammars near beginning of call. there high levels of recognition concurrency without opportunity cache (platform issue @ time), lead scaling challenges (intermittent, large latencies in recognition processing).