Question about unimrcp client

[Haidy]

I'm new to unimrcp and I wanted to ask a question about the client

Is it possible that the unimrcp client connects to multiple servers
concurrently at the same time?
for example: sending an audio stream to multiple asr engines at the
same time (each on a server) and compare their performance or
something

What I understood was that we can create multiple profiles and
configure them to communicate with multiple servers
also from the documentation "Profile will be chosen based on session
management (signaling) agent MRCP session is created or originated
by."
Does that mean that a client can have multiple sessions for each
profile at the same time?

If I'm wrong please correct me with simple steps :)
Thanks in advance

[Randy Olson]

I believe that the sample client is limited to a single session. One
could use the client libraries to create a client that would create
multiple sessions. Whether the multiple sessions connect to different
asr servers or the same asr server depends on whether the client
selects different profiles or the same profile for each session. If
you want to stream the same data to multiple servers you could open
sessions to multiple servers and stream the same data to each of the
servers. It really isn't any different the serially doing the
recognitions to the different servers. The only difference is you
will be running the sessions in parallel.

[HBassily]

Thanks for your reply,
I was thinking of executing each session in a thread. Any guidelines
other than that?
Thank you.

[Randy Olson]

It is hard to comment specifically without a detailed knowledge of what you are doing, but from my own experience devoting a thread to each session is rarely a good design.  The unimrcp client libraries are well written and they avoid the over-use of threads.  Typically I have a "command and control" thread that initiates the sessions and then I let the unimrcp client libraries create the threads that they need.  The client libraries obtain data via callbacks to functions that are registered when the session is created.  With this design, I believe that I have something in the area of 8-12 threads running hundreds of sessions.

On Sunday, May 22, 2011 6:21:00 AM UTC-5, HBassily wrote:

Thanks for your reply,
I was thinking of executing each session in a thread. Any guidelines
other than that?
Thank you.