Sim:Vox: Difference between revisions

From The Dreadnought Project
Jump to navigationJump to search
No edit summary
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 2: Line 2:


==What I Have==
==What I Have==
A zip file of my code can be found [http://dreadnoughtproject.org/friends/vox here]. it is about 50MB.
I have a Zip file of the code that is about 45MB.  I will convey that to anyone working on the project separately.


Please forgive the stupidity of the present build environment -- I really do not know the right way to do such things, and the part of this that we're looking at is taken from Android's codebase.   
===It's Ugly, sorry===
Removing that build environment's fingerprints was difficult for me, but I have successfully made the code build a JNI-compatible library on the Mac.  
The build environment in that ZIP file is ugly.  I really do not know the right way to do such things, and the part of this that we're looking at is taken from Android's codebase.   
Removing that build environment's greasy fingerprints was difficult for me, but I successfully made the code build a JNI-compatible library on the Mac some years ago.
 
I can no longer build it, owing to evolution of my development machine, but it is close.


==Deliverable==
==Deliverable==
The contractor must deliver to me a modified version of a source tree handed which successfully builds a Windows DLL suitable for use by a Java app.  It is not sufficient to hand me a built DLL, as I will need to work on this further.
The contractor must deliver to me a modified version of a source tree which successfully builds a Unity3D plugin that works on Mac and Windows.


==The build environment==
==The build environment==
The project is called "Vox", and is intended to offer VOIP and speech recognition support to Java appsWe are only working on the speech recognition here: "SREC".
The plug-in is part of a project called "Vox" intended to offer VOIP and speech recognition support to Unity gamesVOIP is coming along nicely, but the next challenge is speech recognition using the SREC recognizer distributed as part of the  Android project.


Within the top, "vox" directory, you will see '''Makefile.vox'''  It has some parts at the top that you may well want to edit:
Within the top, "vox" directory, you will see '''Makefile.vox'''  It has some parts at the top that you may well want to edit:
Line 17: Line 20:
* VOX_MACHINE is what tells the rest of the makefiles that this is WIN32 (or MAC or...)
* VOX_MACHINE is what tells the rest of the makefiles that this is WIN32 (or MAC or...)


There is also a $(VOX_ROOT_DIR)/build folder with subfolders that are meant to show how various platforms (e.g., MAC and WIN) do things such as build a static library or a JNI library.
There is also a $(VOX_ROOT_DIR)/build folder with subfolders that are meant to show how various platforms (e.g., MAC and WIN) do things such as build a static library or a JNI library.


It would be nice if you can make changes to files in $(VOX_ROOT_DIR)/build/WIN to make this work.  
It would be nice if you can make changes to files in $(VOX_ROOT_DIR)/build/WIN to make this work.  


I created two simple scripts in $(VOX_ROOT_DIR) to make the entire tree and clean it:  "doit" and "clean"
I created two simple scripts in $(VOX_ROOT_DIR) to make the entire tree and clean it:  "doit" and "clean", e.g.:
* ./doit
* ./clean


==BUILDING the SREC .DLL==
==BUILDING the SREC .DLL/.BUNDLE==
The present tree '''almost''' builds what I need.  On the Mac, it successfully builds '''libsrec_jni.jnilib'''
The present tree '''almost''' builds what I need.  On the Mac, it used to successfully build '''libsrec_jni.jnilib''' but no longer quite builds it.


On Windows, I suppose it would be '''libsrec_jni.dll'''
On Windows, I suppose it would be '''libsrec_jni.dll'''
Line 47: Line 52:
cd zipfile ; make ; cd -
cd zipfile ; make ; cd -
cd tinyxml ; make ; cd -
cd tinyxml ; make ; cd -
cd srec/tools/thirdparty/OpenFst/fst/lib ; make ; cd -


echo This is the critical step!   
echo This is the critical step!   
cd srec/srec_jni ; make ; cd -
cd srec/srec_jni ; make ; cd -


echo \n\n\n==  ERRORS AFTER HERE NOT A WORRY ==\n\n\n
echo ==  BUILD SREC'S GRAMMAR-COMPILING SUPPORT TOOLS ==
# OPTIONAL SREC TOOLS -- not needed to fulfill the contract
cd srec/tools/grxmlcompile ; make ; cd -
cd srec/tools/grxmlcompile ; make ; cd -
cd srec/tools/make_g2g ; make ; cd -
cd srec/tools/make_g2g ; make ; cd -


# VOIP THINGS -- also not needed to satisfy contract
</pre>
cd voip ; make ; cd -
 
cd speex_jni ; make ; cd -
==BROKEN THINGS==
 
These are written from the standpoint of my own experience using command line tools on OS X.
 
===LIBFST===
libfst 1.3.2 (once?) distributed with Android is no longer buildable. 
 
Go to openfst.org and obtain version 1.5.1 and build the libfst static library by hand.  You will need to specify
 
:'''./configure --enable-static=yes; make; make install'''


Find libfst.(whatever) (it goes to /usr/local/lib on OS X) and copy it to $(VOX_ROOT_DIR)/lib and let's see how things go from there
===Missing Symbols when Building the JNILIB===
I am not sure what broke here, but symbols that should be in the srec/srec/Recognizer build step are not found when building srec/srec_jni.  It may be name mangling. 
<pre>
g++  -m32 -arch i386 -DOS_UNIX=8 -DOS_EMBEDDED=16 -DOS_VXWORKS=32 -DOS_PSOS=64 -DOS_QNX=1024 -DOS=4 -DHOST_OS=4 -DTARGET_OS=4 -DCPU_PPC=16 -DCPU_SPARC=32 -DCPU_ARM=64 -DCPU_STRONGARM=128 -DCPU_TMS320X=256 -DCPU_SH3=512 -DCPU_SH4=1024 -DCPU=1 -DHOST_CPU=1 -DTARGET_CPU=1 -DC_GNU=64 -DC_SUNPRO=128 -DC_METROWERKS=512 -DC_TICXC=2048 -DC_ARM=4096 -DCOMPILER=64 -DBUILD_SHIP=1 -DBUILD_DEBUG=8 -DBUILD=1  -DNDEBUG -D_SHIP -DFINAL_RELEASE -D_OPTIMIZE  -I/Users/tone/Documents/code/vox/srec/shared/include -I/Users/tone/Documents/code/vox/srec/portable/include -I/Users/tone/Documents/code/vox/srec/srec/include -I/Users/tone/Documents/code/vox/srec/srec/ca -I/Users/tone/Documents/code/vox/srec/srec/EventLog/include -I/Users/tone/Documents/code/vox/srec/srec/Session/include -I/Users/tone/Documents/code/vox/srec/srec/Semproc/include -I/Users/tone/Documents/code/vox/srec/srec/Recognizer/include -I/Users/tone/Documents/code/vox/srec/srec/Grammar/include -I/Users/tone/Documents/code/vox/srec/srec/Nametag/include -I/Users/tone/Documents/code/vox/srec/srec/Vocabulary/include -I/Users/tone/Documents/code/vox/srec/srec/AcousticModels/include -I/Users/tone/Documents/code/vox/srec/srec/AcousticState/include -I/Users/tone/Documents/code/vox/srec/audio/AudioIn/UNIX/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers -dynamiclib -o /Users/tone/Documents/code/vox/lib/libsrec_jni.jnilib -framework JavaVM -dylib  android_speech_srec_Recognizer.o -L/Users/tone/Documents/code/vox/lib -l ESR_Shared -l ESR_Portable -l SR_AcousticModels -l SR_AcousticState -l SR_Core -l SR_EventLog -l SR_Grammar -l SR_G2P -l SR_Nametag -l SR_Recognizer -l SR_Semproc -l SR_Session -l SR_Vocabulary -l z -l zipfile
clang: warning: argument unused during compilation: '-dylib'
Undefined symbols for architecture i386:
  "_canPushAudioIntoRecognizer", referenced from:
      _SR_RecognizerAdvanceImpl in libSR_Recognizer.a(RecognizerImpl.o)
      _detectBeginningOfSpeech in libSR_Recognizer.a(RecognizerImpl.o)
  "_generateFrameFromAudio", referenced from:
      _SR_RecognizerAdvanceImpl in libSR_Recognizer.a(RecognizerImpl.o)
      _detectBeginningOfSpeech in libSR_Recognizer.a(RecognizerImpl.o)
  "_generateFrameStats", referenced from:
      _SR_RecognizerAdvanceImpl in libSR_Recognizer.a(RecognizerImpl.o)
  "_generatePatternFromFrame", referenced from:
      _SR_RecognizerAdvanceImpl in libSR_Recognizer.a(RecognizerImpl.o)
  "_generatePatternFromFrameEOI", referenced from:
      _SR_RecognizerAdvanceImpl in libSR_Recognizer.a(RecognizerImpl.o)
  "_himul32", referenced from:
      _complex_multiplier in libSR_Core.a(sp_fft.o)
      _do_real_fft_magsq in libSR_Core.a(sp_fft.o)
  "_pushAudioIntoRecognizer", referenced from:
      _SR_RecognizerAdvanceImpl in libSR_Recognizer.a(RecognizerImpl.o)
      _detectBeginningOfSpeech in libSR_Recognizer.a(RecognizerImpl.o)
</pre>
</pre>
===SREC'S grxmlcompile tool is not building===
This may be due to the newer OpenFST version and ties it has to C++/11.
Maybe a C++/11 flag must be added, or perhaps some ">>" signs require a space between them, etc.  I only looked at this a short while.
===The actual plug-in===
The srec/srec_jni folder shows a sample of how the necessary functionality MIGHT be packaged into a JNILib.  This might be a place you will certainly modify to build Unity-compatible plug-ins.


==Other notes==
==Other notes==


# The DLL must be in 32 bit mode to work
# I believe that the speech recognizer code must be compiled in 32 bit mode to work.  It uses runtime datasets that are opaque and are apparently not read correctly by 64 bit code.
If possible, please touch only Makefile.vox and files in srec/srec_jni and build to make this work.  If this approach is just too unpleasant for you, please make alternative Makefiles in the various folders visited by the "doit" script with the name "Makefile.WIN"
I tried to approach this so that necessary changes were likely to be made mostly in Makefile.vox, the files in srec/srec_jni and the files in $(VOX_ROOT_DIR)/build/
#  You must preserve the existing functionality of the build for the Mac, which works now by cd-ing to $(VOX_ROOT_DIR) and typing "./doit" with Makefile.vox edited to indicate a Mac target.
#  You must preserve the existing functionality of the build for the Mac, which works now by cd-ing to $(VOX_ROOT_DIR) and typing "./doit" with Makefile.vox edited to indicate a Mac target.
#  It is also necessary that I receive a build environment I can use for future work.  That is, I do not simply require a .dll file, but a build system that can build it.  My project is still under development, and I will have to continue work on this and similar DLLs.
#  It is also necessary that I receive a build environment I can use for future work.  That is, I do not simply require a .dll file, but a build system that can build it.
# I'd very much like to avoid using Microsoft build tools.  MinGW is what I've been using so far.
# It will take me a day or two to create a real test app for it, but please check that the plug-in loads on Mac and Windows and that a sample native method can be called
#  Please test that Java's System.loadLibrary() call can load your DLL and that a call to the test function Java_android_speech_srec_Recognizer_Moo prints "moo" to the console before declaring success

Latest revision as of 20:55, 3 March 2016

Thank you for looking at my contract.

What I Have

I have a Zip file of the code that is about 45MB. I will convey that to anyone working on the project separately.

It's Ugly, sorry

The build environment in that ZIP file is ugly. I really do not know the right way to do such things, and the part of this that we're looking at is taken from Android's codebase. Removing that build environment's greasy fingerprints was difficult for me, but I successfully made the code build a JNI-compatible library on the Mac some years ago.

I can no longer build it, owing to evolution of my development machine, but it is close.

Deliverable

The contractor must deliver to me a modified version of a source tree which successfully builds a Unity3D plugin that works on Mac and Windows.

The build environment

The plug-in is part of a project called "Vox" intended to offer VOIP and speech recognition support to Unity games. VOIP is coming along nicely, but the next challenge is speech recognition using the SREC recognizer distributed as part of the Android project.

Within the top, "vox" directory, you will see Makefile.vox It has some parts at the top that you may well want to edit:

  • VOX_ROOT_DIR on line 9 should be an absolute path to the vox directory on your filesystem
  • VOX_MACHINE is what tells the rest of the makefiles that this is WIN32 (or MAC or...)

There is also a $(VOX_ROOT_DIR)/build folder with subfolders that are meant to show how various platforms (e.g., MAC and WIN) do things such as build a static library or a JNI library.

It would be nice if you can make changes to files in $(VOX_ROOT_DIR)/build/WIN to make this work.

I created two simple scripts in $(VOX_ROOT_DIR) to make the entire tree and clean it: "doit" and "clean", e.g.:

  • ./doit
  • ./clean

BUILDING the SREC .DLL/.BUNDLE

The present tree almost builds what I need. On the Mac, it used to successfully build libsrec_jni.jnilib but no longer quite builds it.

On Windows, I suppose it would be libsrec_jni.dll

If you look in $(VOX_ROOT_DIR)/doit, you can see the various steps of building pre-requisites, and the final step which fails to build srec_jni:

cd srec/portable ; make ; cd -
cd srec/seti/sltsEngine ; make ; cd -
cd srec/shared ; make ; cd -
cd srec/srec/AcousticModels ; make ; cd -
cd srec/srec/AcousticState ; make ; cd -
cd srec/srec/ca ; make ; cd -
cd srec/srec/EventLog ; make ; cd -
cd srec/srec/Grammar ; make ; cd -
cd srec/srec/Nametag ; make ; cd -
cd srec/srec/Recognizer ; make ; cd -
cd srec/srec/Semproc ; make ; cd -
cd srec/srec/Session ; make ; cd -
cd srec/srec/Vocabulary ; make ; cd -
cd zlib ; make vox ; cd -
cd zipfile ; make ; cd -
cd tinyxml ; make ; cd -

echo This is the critical step!  
cd srec/srec_jni ; make ; cd -

echo ==  BUILD SREC'S GRAMMAR-COMPILING SUPPORT TOOLS ==
cd srec/tools/grxmlcompile ; make ; cd -
cd srec/tools/make_g2g ; make ; cd -

BROKEN THINGS

These are written from the standpoint of my own experience using command line tools on OS X.

LIBFST

libfst 1.3.2 (once?) distributed with Android is no longer buildable.

Go to openfst.org and obtain version 1.5.1 and build the libfst static library by hand. You will need to specify

./configure --enable-static=yes; make; make install

Find libfst.(whatever) (it goes to /usr/local/lib on OS X) and copy it to $(VOX_ROOT_DIR)/lib and let's see how things go from there

Missing Symbols when Building the JNILIB

I am not sure what broke here, but symbols that should be in the srec/srec/Recognizer build step are not found when building srec/srec_jni. It may be name mangling.

g++   -m32 -arch i386 -DOS_UNIX=8 -DOS_EMBEDDED=16 -DOS_VXWORKS=32 -DOS_PSOS=64 -DOS_QNX=1024 -DOS=4 -DHOST_OS=4 -DTARGET_OS=4 -DCPU_PPC=16 -DCPU_SPARC=32 -DCPU_ARM=64 -DCPU_STRONGARM=128 -DCPU_TMS320X=256 -DCPU_SH3=512 -DCPU_SH4=1024 -DCPU=1 -DHOST_CPU=1 -DTARGET_CPU=1 -DC_GNU=64 -DC_SUNPRO=128 -DC_METROWERKS=512 -DC_TICXC=2048 -DC_ARM=4096 -DCOMPILER=64 -DBUILD_SHIP=1 -DBUILD_DEBUG=8 -DBUILD=1   -DNDEBUG -D_SHIP -DFINAL_RELEASE -D_OPTIMIZE  -I/Users/tone/Documents/code/vox/srec/shared/include -I/Users/tone/Documents/code/vox/srec/portable/include -I/Users/tone/Documents/code/vox/srec/srec/include -I/Users/tone/Documents/code/vox/srec/srec/ca -I/Users/tone/Documents/code/vox/srec/srec/EventLog/include -I/Users/tone/Documents/code/vox/srec/srec/Session/include -I/Users/tone/Documents/code/vox/srec/srec/Semproc/include -I/Users/tone/Documents/code/vox/srec/srec/Recognizer/include -I/Users/tone/Documents/code/vox/srec/srec/Grammar/include -I/Users/tone/Documents/code/vox/srec/srec/Nametag/include -I/Users/tone/Documents/code/vox/srec/srec/Vocabulary/include -I/Users/tone/Documents/code/vox/srec/srec/AcousticModels/include -I/Users/tone/Documents/code/vox/srec/srec/AcousticState/include -I/Users/tone/Documents/code/vox/srec/audio/AudioIn/UNIX/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers -dynamiclib -o /Users/tone/Documents/code/vox/lib/libsrec_jni.jnilib -framework JavaVM -dylib  android_speech_srec_Recognizer.o -L/Users/tone/Documents/code/vox/lib -l ESR_Shared -l ESR_Portable -l SR_AcousticModels -l SR_AcousticState -l SR_Core -l SR_EventLog -l SR_Grammar -l SR_G2P -l SR_Nametag -l SR_Recognizer -l SR_Semproc -l SR_Session -l SR_Vocabulary -l z -l zipfile 
clang: warning: argument unused during compilation: '-dylib'
Undefined symbols for architecture i386:
  "_canPushAudioIntoRecognizer", referenced from:
      _SR_RecognizerAdvanceImpl in libSR_Recognizer.a(RecognizerImpl.o)
      _detectBeginningOfSpeech in libSR_Recognizer.a(RecognizerImpl.o)
  "_generateFrameFromAudio", referenced from:
      _SR_RecognizerAdvanceImpl in libSR_Recognizer.a(RecognizerImpl.o)
      _detectBeginningOfSpeech in libSR_Recognizer.a(RecognizerImpl.o)
  "_generateFrameStats", referenced from:
      _SR_RecognizerAdvanceImpl in libSR_Recognizer.a(RecognizerImpl.o)
  "_generatePatternFromFrame", referenced from:
      _SR_RecognizerAdvanceImpl in libSR_Recognizer.a(RecognizerImpl.o)
  "_generatePatternFromFrameEOI", referenced from:
      _SR_RecognizerAdvanceImpl in libSR_Recognizer.a(RecognizerImpl.o)
  "_himul32", referenced from:
      _complex_multiplier in libSR_Core.a(sp_fft.o)
      _do_real_fft_magsq in libSR_Core.a(sp_fft.o)
  "_pushAudioIntoRecognizer", referenced from:
      _SR_RecognizerAdvanceImpl in libSR_Recognizer.a(RecognizerImpl.o)
      _detectBeginningOfSpeech in libSR_Recognizer.a(RecognizerImpl.o)

SREC'S grxmlcompile tool is not building

This may be due to the newer OpenFST version and ties it has to C++/11.

Maybe a C++/11 flag must be added, or perhaps some ">>" signs require a space between them, etc. I only looked at this a short while.

The actual plug-in

The srec/srec_jni folder shows a sample of how the necessary functionality MIGHT be packaged into a JNILib. This might be a place you will certainly modify to build Unity-compatible plug-ins.

Other notes

  1. I believe that the speech recognizer code must be compiled in 32 bit mode to work. It uses runtime datasets that are opaque and are apparently not read correctly by 64 bit code.
  2. I tried to approach this so that necessary changes were likely to be made mostly in Makefile.vox, the files in srec/srec_jni and the files in $(VOX_ROOT_DIR)/build/
  3. You must preserve the existing functionality of the build for the Mac, which works now by cd-ing to $(VOX_ROOT_DIR) and typing "./doit" with Makefile.vox edited to indicate a Mac target.
  4. It is also necessary that I receive a build environment I can use for future work. That is, I do not simply require a .dll file, but a build system that can build it.
  5. It will take me a day or two to create a real test app for it, but please check that the plug-in loads on Mac and Windows and that a sample native method can be called