cairo-developer — List for Cairo developer discussions of coding, changes, and architecture

[Cairo-developer] Sphinx Arabic Support

[Furqan B. <h_...@ya...>]

Hi,

I am a Graduate Student from Pakistan. I am looking for support for Arabic language for Speech Recognition. I have recently worked with Sphinx in Android i.e Android pocketSphinx, and was wondering if I could get some support for Arabic in Sphinx as well. I would really appreciate if you can help or guide me in this.
 
Regards
Furqan Baig

[Cairo-developer] Using cairo client with a MRCP TTS engine

[Iman S. <ima...@gm...>]

Hi,

I want to integrate cairo client with my own TTS engine that implements MRCP
protocol and uses SIP sofia. I need some hints on how to do this. I
downloaded the source code of the client and compiled it successfully, I
need to know what are the values that need to be changed so that the client
can communicate with the TTS engine.

Iman

[Cairo-developer] Releasing resources at end of sessions

[slord <sa...@us...>]

Hi,
I am working on adding the capability to release resources when they are no
longer needed by a session.  There are 3 processes that play  a role.  Each
process may (in theory)  be on different machines.  The process are:

1).  ResourceManager  (RM)      -- gets sip requests then finds reciever
and/or transmitter resources as needed
2).  TransmitterResource (TR)   -- transmitter resources have speech synth
pools.  Requests forwarded from the RM cause the creation of RTP and MRCP
channels that use transmitter resources.
3). ReceiverResource (RR)      -- transmitter resources have pools or recong
engines.  Requests forwarded from the RM cause the creation of RTP and MRCP
channels that use receiver resources.

Before being able to release resources, I want to add sessions and session
containers to keep track of the resources that have been allocated.  

http://www.nabble.com/file/p13286074/image001.gif 

(The term resource is overloaded here.  The Transmitter and Receiver
resources are processes that manage pools of speech recognition  and
synthesis engines.  When an invitation is received by a RR or TR it creates
MRCP and RTP channels as needed.  These channels use the pools of speech
recognition and synthesis engines (managed by the TR and RR) -- which are
already returned to the pools when they are done using them.  The resources
that need to be managed -- and I am addressing here -- are the RTP and MRCP
channels allocated within the resource processes.)

My first thought was to have a single session in the RM that can have remote
references to the RTP and MRCP channels.  That seems reasonable for handling
bye requests where it is just a matter of shutting down the channels, but it
seems a little awkward for re-invites.  Re-invites seem better handled by
going through the resource server -- just like the initial invite.   And in
general, it seems like the resource servers are marginalized if there are
remote references to the channels directly from the RM.

The approach I am now taking is to have separate sessions on each
Server/process (RM, TR, RR).  The RM session will keep track of which
resource servers are being used by the SIP Session.  The TR and RR will keep
track of the channels they are using for the sessions.

All sessions will use the sip sessionid for the sessionid.

I will create a generic session container that has a housekeeping thread
that cleans up sessions after a programmable timeout

I will have a callback mechanism so that special processing can be hooked in
(if needed) when a session times out.

The main problem I see with this approach is that there are 3 separate
sessions all with their own timeouts and there could be inconsistencies
between them.  Perhaps the callback mechanism could be used to check the
other resources for consistency.

Any thought on this approach or any suggestions for other approaches?

Thanks,
Spencer
-- 
View this message in context: http://www.nabble.com/Releasing-resources-at-end-of-sessions-tf4650434.html#a13286074
Sent from the cairo-developer mailing list archive at Nabble.com.