unimrcp installation - apr_pool_mutex_set

[Josef Novak]

Hi,

I'm new to UniMRCP and have just tried to build and install the
distribution with the latest tarballs,
deps
http://unimrcp.googlecode.com/files/unimrcp-deps.tar.gz (Unix)
UniMRCP
http://unimrcp.googlecode.com/files/unimrcp-0.7.0.tar.gz

I also tried the SVN code, and although I have no trouble building
and installing either of these distributions, every time I try to run
the actual resulting binaries I get an error,

/usr/local/unimrcp/bin/$ ./unimrcpserver
/usr/local/unimrcp/bin/unimrcpserver: symbol lookup error:
/usr/local/unimrcp/lib/libunimrcpserver.so.0: undefined symbol:
apr_pool_mutex_set

I know this is addressed in several e-mails, as well as in an
available patch, but the patch appears to have already been applied to
the latest deps tarball so I'm a bit lost as to how I might proceed.

I am running debian 5.0 lenny.

[Arsen Chaloyan]

Hi Josef,
Honestly I started to think this is the same trivial issue, but well, you are aware of the dependency package e.t.c.

Debian comes with some APR version installed. Most probably you compile and link UniMRCP with correct APR package, but at run rime, it tries to find apr_pool_mutex_set in APR package from Debian distribution.
Try "ldd /usr/local/unimrcp/lib/libunimrcpserver.so" to identify which APR version unimrcpserver uses.

Also try to explicitly specify where to look for APR at configure time
./configure --with-apr=/usr/loca/apr  --with-apr-util=/usr/loca/apr
or pointing out source directory instead
./configure --with-apr=path_to_apr_src  --with-apr-util=path_to_apr_util_src

This might be a typical problem on Debian, so please go ahead and let us know the results.

--
Arsen Chaloyan
The author of UniMRCP
http://www.unimrcp.org

[Josef Novak]

Hi,

Thanks so much for the quick reply, it was just what I needed to
work out what was wrong.
The short answer is that the presence of the default debian apr
packages was obscuring the fact that the new packages from
unimrcp-deps were not included in the loadpath. The solution was
simply to append the new packages to the loadpath,

$ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/apr/lib

It took me a while to figure out exactly what was going wrong, and
I did it while writing this email, so I'll include the rest for
posterity - perhaps it will be of help to others.

First, the result of the command you recommended, indicates that you
were right.
unimrcp# ldd /usr/local/unimrcp/lib/libunimrcpserver.so
linux-gate.so.1 => (0x001f2000)
libapr-1.so.0 => /usr/local/apr/lib/libapr-1.so.0 (0x008be000)
librt.so.1 => /lib/i686/nosegneg/librt.so.1 (0x0099a000)
libcrypt.so.1 => /lib/i686/nosegneg/libcrypt.so.1 (0x0049d000)
libpthread.so.0 => /lib/i686/nosegneg/libpthread.so.0 (0x00a13000)
libdl.so.2 => /lib/i686/nosegneg/libdl.so.2 (0x004d1000)
libaprutil-1.so.0 => /usr/local/apr/lib/libaprutil-1.so.0 (0x00deb000)
libexpat.so.0 => /usr/local/apr/lib/libexpat.so.0 (0x003eb000)
libsofia-sip-ua.so.0 => /usr/local/lib/libsofia-sip-ua.so.0 (0x001f3000)
libc.so.6 => /lib/i686/nosegneg/libc.so.6 (0x00a43000)
/lib/ld-linux.so.2 (0x80000000)

So first I tried to rebuild unimrcp with the configure options you
recommended, however this did not solve the problem. I also tried
rebuilding apr, and then rebuilding the apr-util package from the
unimrcp-deps separately rather than with the unified compile script.
I did this in order to specify the apr package for apr-util, with
../apr-util$ ./configure --with-apr=/path/to/unimrcp-deps/libs/apr

and then again rebuilding the unimrcp package. None of this worked,
as I still received the same error message, which basically meant
that, as you had thought, unimrcp was still relying on the default
debian apr libs.
So I removed the default debian apr packages I had installed,
$ apt-get remove apt-get remove libapr1

I then rebuilt everything again from scratch, with the specific
configure options, make install, etc.
Finally I added it the new apr packages to the path,
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/apr/lib

and everything worked,

/usr/local/unimrcp/bin$ ./unimrcpserver
2009-08-27 06:42:24:924040 [NOTICE] UniMRCP Server [0.7.0]
2009-08-27 06:42:24:924181 [INFO] APR [1.3.6]
2009-08-27 06:42:24:924291 [NOTICE] Create MRCP Server
2009-08-27 06:42:24:924333 [NOTICE] Create MRCP Resource Factory [2]
2009-08-27 06:42:24:924362 [NOTICE] Register Synthesizer Resource
2009-08-27 06:42:24:924371 [NOTICE] Register Recognizer Resource
2009-08-27 06:42:24:924386 [INFO] Register Resource Factory
2009-08-27 06:42:24:924426 [INFO] Register Codec [LPCM]
2009-08-27 06:42:24:924433 [INFO] Register Codec [PCMU]
2009-08-27 06:42:24:924437 [INFO] Register Codec [PCMA]
2009-08-27 06:42:24:924454 [INFO] Register Codec [L16]
2009-08-27 06:42:24:924473 [NOTICE] Open Config File [../conf/unimrcpserver.xml]
2009-08-27 06:42:24:924528 [WARN] Failed to Open Config File
[../conf/unimrcpserver.xml]
2009-08-27 06:42:24:924536 [INFO] Start MRCP Server
>2009-08-27 06:42:24:924633 [INFO] Open Resource Engines
2009-08-27 06:42:24:924655 [NOTICE] MRCP Server Started


This made me wonder if the library path was the problem all along,
i.e., I had built and installed the libraries, and because I hadn't
added it to the loadpath the build or runtime was backing off to the
default apr packages.
I tried resetting the library path,
unimrcp/bin$ export LD_LIBRARY_PATH=
unimrcp/bin$ ./unimrcpserver
./unimrcpserver: symbol lookup error:
/usr/local/unimrcp/lib/libunimrcpserver.so.0: undefined symbol:
apr_pool_mutex_set
unimrcp/bin$ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/apr/lib
unimrcp/bin$ ./unimrcpserver
2009-08-27 06:48:55:289055 [NOTICE] UniMRCP Server [0.7.0]
2009-08-27 06:48:55:289201 [INFO] APR [1.3.6]
2009-08-27 06:48:55:289355 [NOTICE] Create MRCP Server
2009-08-27 06:48:55:289397 [NOTICE] Create MRCP Resource Factory [2]
2009-08-27 06:48:55:289418 [NOTICE] Register Synthesizer Resource
2009-08-27 06:48:55:289438 [NOTICE] Register Recognizer Resource
2009-08-27 06:48:55:289465 [INFO] Register Resource Factory
2009-08-27 06:48:55:289484 [INFO] Register Codec [LPCM]
2009-08-27 06:48:55:289492 [INFO] Register Codec [PCMU]
2009-08-27 06:48:55:289516 [INFO] Register Codec [PCMA]
2009-08-27 06:48:55:289537 [INFO] Register Codec [L16]
2009-08-27 06:48:55:289579 [NOTICE] Open Config File [../conf/unimrcpserver.xml]
2009-08-27 06:48:55:289613 [WARN] Failed to Open Config File
[../conf/unimrcpserver.xml]
2009-08-27 06:48:55:289627 [INFO] Start MRCP Server
>2009-08-27 06:48:55:289709 [INFO] Open Resource Engines
2009-08-27 06:48:55:289729 [NOTICE] MRCP Server Started


Sure enough the LD_LOAD_PATH was the only problem the whole time.
My apologies for not spotting this from the beginning. The presence
of the default debian apr packages was obscuring the fact that the new
packages from unimrcp-deps were not included in the loadpath.

Thanks again for the feedback!

Cheers,
-Joe

[Arsen Chaloyan]

On Thu, Aug 27, 2009 at 11:53 AM, Josef Novak <josef.rob...@gmail.com> wrote:

Hi,

 Thanks so much for the quick reply, it was just what I needed to
work out what was wrong.

 

Well.

 The short answer is that the presence of the default debian apr
packages was obscuring the fact that the new packages from
unimrcp-deps were not included in the loadpath.  The solution was
simply to append the new packages to the loadpath,

$ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/apr/lib

 

Please add a comment in http://code.google.com/p/unimrcp/wiki/SupportedPlatforms and outline this workaround

  It took me a while to figure out exactly what was going wrong, and
I did it while writing this email, so I'll include the rest for
posterity - perhaps it will be of help to others.

 

Thanks, makes sense.

Even though I see you have no unimrcpserver.xml in place. It should be installed in /usr/loca/unimrcp/conf by make install

No problem, that's why the discussion group exists.

The presence of the default debian apr packages was obscuring the fact that the new
packages from unimrcp-deps were not included in the loadpath.

 

Exactly.

[Josef Novak]

Hi,

I have two more questions which are specific to the pocketsphinx plugin.

I had no problem building and configuring the pocketsphinx plugin,
and it is pretty awesome, but I would like to know about extending it
to support ngram language models. After looking at the plugin source
it seems it should be fairly straightforward to swap out or add in the
pocketsphinx command line parameter '-lm' for the current default
'-jsfgs' parameter. After this we'll have support for ngram style
langauge models.

a.) Is there any particular reason why ngram grammars aren't yet
supported? Pocketsphinx supports these out of the box. Will changing
it have further knock-on effects that I have not foreseen? Is there
an interest in this added functionality? (I guess that is more than
one question but..)

b.) I noticed in the plugin that you are using
mpf_activity_detector to handle voice activity detection. Is there
any reason why you chose to employ this, rather than the VAD support
in the sphinxbase source?


Cheers,
Joe

On Thu, Aug 27, 2009 at 2:32 PM, Arsen Chaloyan<acha...@gmail.com> wrote:

[Arsen Chaloyan]

Well, small story behind Pocketsphinx integration, which should answer the questions you have.
Originally PocketSphinx was and still is integrated in FreeSWITCH as an ASR plugin. UniMRCP integration allows to offload FreeSWITCH and use PocketSphinx via MRCP. Thus, the primary goal was to make FreeSWITCH, UniMRCP and PocketSphinx, Flite work as a whole. In the meantime, UniMRCP PocketSphinx integration should work with any MRCP and grammar compliant clients.

See my answers below,

On Thu, Aug 27, 2009 at 12:54 PM, Josef Novak <josef.rob...@gmail.com> wrote:

Hi,

 I have two more questions which are specific to the pocketsphinx plugin.

 I had no problem building and configuring the pocketsphinx plugin,
and it is pretty awesome, but I would like to know about extending it
to support ngram language models.  After looking at the plugin source
it seems it should be fairly straightforward to swap out or add in the
pocketsphinx command line parameter '-lm' for the current default
'-jsfgs' parameter.  After this we'll have support for ngram style
langauge models.

  a.) Is there any particular reason why ngram grammars aren't yet
supported?

 

Nobody was interested in N-GRAM support before. However it's indeed should be straightforward to add.

 Pocketsphinx supports these out of the box.  Will changing
it have further knock-on effects that I have not foreseen?

I guess, no.

 Is there an interest in this added functionality?

Yes.
 

(I guess that is more than one question but..)

Feel free to raise them up.

  b.) I noticed in the plugin that you are using
mpf_activity_detector to handle voice activity detection.  Is there
any reason why you chose to employ this, rather than the VAD support
in the sphinxbase source?

Initially I expected that recognition engine should be capable to detect start and end of utterance itself. However I was just surprised that PocketSphinx didn't support this. Perhaps there is still a learning curve for me, I was not familiar with either PocketSphinx or SphinxBase before and I spent only a week or two on the integration.
Can you please elaborate on this?
If you mean vader included into PocketSphinx distribution, I'm afraid, it's not possible to use it due to license incompatibility between GPLv2 and Apache.

[Josef Novak]

Hi,
Thanks again for the helpful reply.
Actually the code I was referring to is not the vader plugin for
gstreamer, but older source from the sphinxbase lbraries. In
particular, the libsphinxam code,
$ sphinxbase/src/libsphinxad/cont_ad_base.c

which is employed to construct the 'utterance_loop' function for the
pocketsphinx_continous program,
$ pocketsphinx/src/programs/continuous.c

as well as the file-based segmenter,
$ sphinxbase/src/sphinx_adtools/cont_fileseg.c

cont_ad_base contains most of the functions necessary to detect the
silence vs. speech effectively and I've found it to be pretty
effective in past. the cont_fileseg.c gives and example of adapting
the detector to a file stream.

im not one hundred percent sure that it is appropriate to this
application, but it might be possible to adapt it without too much
trouble. in particular it would probably be necessary to implement an
alternative ad_read function appropriate for a socket (i haven't
actually tried this yet so i may be wrong).


cheers,
Joe

[Arsen Chaloyan]

Thanks for the clarification.
Your expertise in this area should be very helpful for the project.
If you happen to further enhance the plugin, do not forget to contribute your changes back to the project.