Re: [Kaldi-users] Using SWIG to wrap kaldi for python

[Ondrej P. <ond...@gm...>]

I forget to mention that cffi is really good for interfacing C,
but it is quite tedious to generate templated functions from C++ using cffi.

The cython pyfst wrapper uses mustache templates to do the job
of C++ preprocessor and I needed to modify only small pieces of code.

Ondra


On 11 December 2013 20:51, Ondrej Platek <ond...@gm...> wrote:

> Hi,
>
> just a quick notice: I abandon cffi in favor to cython,
> because I found really nice python wrapper around fst called pyfst
> http://pyfst.github.io/
>
> Now, I am able to work with fst objects in Python (Currently only Log and
> standard semiring are supported and I am always using VectorFst object).
>
> Cheers,
>
> Ondra
>
>
> On 11 December 2013 19:27, Daniel Povey <dp...@gm...> wrote:
>
>> Sorry, changing the list recipient to kaldi-users which is a real,
>> existing list.
>> Dan
>>
>>
>>
>> On Wed, Dec 11, 2013 at 1:16 PM, Daniel Povey <dp...@gm...> wrote:
>>
>>> Matthew,
>>>
>>> This is interesting.  People frequently ask me about how to wrap Kaldi
>>> in scripting languages such as Python.
>>> I'm cc'ing kaldi-discuss, so it gets archived for web search, and a
>>> couple more people who I think may be interested.
>>> For people's reference, the change you just checked in is here:
>>>  http://sourceforge.net/p/kaldi/code/3297/
>>> Ondrej Platek has another method, based on CFFI, that can be found
>>> at  ^/sandbox/oplatek2/src/pykaldi
>>> (where ^ is the top of the Kaldi source tree, i.e. svn://
>>> svn.code.sf.net/p/kaldi/code/), and Danijel Korzinek has used Java,
>>> which can be found at
>>> ^/sandbox/korzinek/src/onlinebin/java-online-audio-client/
>>> At this point, I'm not sure that I want to settle on one "official" way
>>> to wrap Kaldi, I'd rather have people demonstrate various ways to do it and
>>> people can choose what they want for their application.
>>>
>>> Dan
>>>
>>>
>>>
>>> On Wed, Dec 11, 2013 at 11:06 AM, Matthew Aylett <
>>> mat...@gm...> wrote:
>>>
>>>> Hi all
>>>>
>>>> I've checked in some code which is a fairly vanilla use of SWIG to wrap
>>>> kaldi functionality.
>>>>
>>>> The logic for this for me was to allow me to easily convert kaldi trees
>>>> into HTK ones to test v HTS (not a long term functionality so maybe not
>>>> the best example).
>>>>
>>>> The idea was to wrap the io code to avoid rewriting scripts to read in
>>>> and parse ascii outputs.
>>>>
>>>> In effect you give python function to load the object and traverse it
>>>> as well as accessing info that is required.
>>>>
>>>> In order to do this I had to add some accesor function on event-map.h
>>>>
>>>> If you check out the idlak branch you will find:
>>>>
>>>> idlak-voice-build/pythonlib
>>>>
>>>> In here we have:
>>>>
>>>> Makefile:
>>>>
>>>> This is to wrap the api using SWIG. There is an issue of where it gets
>>>> the binary swig from (versions can behave differently and error
>>>> differently). At present it just picks it up from the path which is not
>>>> ideal.
>>>>
>>>> Also it needs to find the python library. This varies by platfom (it is
>>>> present on Mac but not completely obvious). I've only tested this for linux.
>>>>
>>>> idlakapi.i:
>>>>
>>>> This is the swig interface file. As you will see I don't do anything
>>>> much in this apart from include headers. Although if you need to add
>>>> callbacks etc there are ways of doing this here to take into account the
>>>> python GlobalInterpreterLock.
>>>>
>>>> idlakapi.h:
>>>>
>>>> This si the API I am wrapping. In effect I am adding another layer
>>>> which then indirectly accesses kaldi structures. I do this because I don't
>>>> like wrapping .h files that haven't been written for the purpose. In my
>>>> experience the dependencies get out of hand and you end up wrapping tons
>>>> more stuff than you want. In this approach you add functions as you require
>>>> them for real pythin (or java etc) applications.
>>>>
>>>> idlakapi.cc:
>>>>
>>>> This is the code which directly accesses the kaldi library functions.
>>>>
>>>> example.py:
>>>>
>>>> A little python program which reads in a context dependency tree and
>>>> prints it out. In effect duplicating copy-tree --binary=false in.tree -
>>>>
>>>> (well almost it adds a CR at the end of the file)
>>>>
>>>> However this does it by traversing and accessing the EventMaps in the
>>>> tree. Currently only works on binary trees.
>>>>
>>>> Questions:
>>>>
>>>> Why wrap at all?
>>>>
>>>> Well handy for things like realtime decoders. For me I find it  a very
>>>> quick way of developing new stuff quickly because you can jump into python
>>>> and use a whole load of available stuff and jump back to C++ then you write
>>>> the C++ once it works.
>>>>
>>>> However it is a bit dangerous with kaldi because you have a nice
>>>> command line style format and if mis-handled could lead to a much dirtier
>>>> looking code base. The last thing I'd want to see is the way festival used
>>>> Scheme. So an absolute ban on scary things like C++ code calling python
>>>> programs.
>>>>
>>>> For the voice building process it will speed up development for me but
>>>> if you guys want me to replace this with command line versions I can do so.
>>>> Probably should in the long run anyway.
>>>>
>>>> Why wrap like this?
>>>>
>>>> Well I think SWIG is good because it allows you to wrap in multiple
>>>> languages (even Perl ;-)
>>>>
>>>> I like it to be clear what is being wrapped and to keep it seperate
>>>> from the main code base. I would suggest the same thing with producing a C
>>>> API as well.
>>>>
>>>> But there are a lot of ways to skin this and its really up to the
>>>> community to decide which they want to do it (if at all). Here is an
>>>> example. If the consensus is to do it a different way I'm happy to change
>>>> it but I think its useful to have a working example. I am by no means a
>>>> Makefile expert either so this may need changing, it is basically assuming
>>>> a load of static libraries and pretending the spi is like a bin program.
>>>>
>>>> By the way is anyone now keeping my branch up to date with the trunk?
>>>> Arnab was doing so but he may not have time now. I can do it if you remind
>>>> me what the commands are.
>>>>
>>>> Happy Xmas etc.
>>>>
>>>> Matthew
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jul 16, 2013 at 4:00 PM, ondrej platek <ond...@se...
>>>> > wrote:
>>>>
>>>>> Thanks, for a very positive answer and useful information. I should
>>>>> learn SWIG probably:)
>>>>>
>>>>> I am very interested in the example SWIG wrapping into idlak.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Ondra
>>>>>
>>>>>
>>>>> On Tue, Jul 16, 2013 at 4:27 PM, Matthew Aylett <mat...@ce...
>>>>> > wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> See below
>>>>>>
>>>>>>  I will add very quick notes about SWIG in following pros and cons
>>>>>>> list:
>>>>>>>
>>>>>>> Pros:
>>>>>>> - Multiple languages - not interesting for me
>>>>>>>
>>>>>> Faire enough but might be useful for kaldi community
>>>>>>
>>>>>>
>>>>>>  - Once setup makefiles it works - interesting for me
>>>>>>>
>>>>>>
>>>>>> Well that ain't so easy but there should be examples.  I have tended
>>>>>> to use cmake to do the heavy lifting for me here but its not ideal and not
>>>>>> used in kaldi.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Cons
>>>>>>> - If the API C/C++ API is changed you need to changed on 3 places (1
>>>>>>> more place for *.i)
>>>>>>>
>>>>>>
>>>>>> 1 place in the C API. The header file is included into SWIG not
>>>>>> copied. However...
>>>>>>
>>>>>>
>>>>>>    What worse if the API changes just in C++ and somebody forget to
>>>>>>> update the interface file,
>>>>>>>
>>>>>>
>>>>>> Yes this is an issue. But one that comes with a C API. So not
>>>>>> specific to SWIG. Maintaining a seperate C API requires keeping it updated
>>>>>> with the underlying C++ libs. This can be more problematic if you say
>>>>>> define a struct once for an internal C header and then again for an
>>>>>> external one (typically the compiler won't spot that either so you are in
>>>>>> trouble).
>>>>>>
>>>>>> I would say that having the external C API is good discipline if we
>>>>>> are serious at cross platform support but maybe no really an issue at this
>>>>>> time.
>>>>>>
>>>>>>
>>>>>>    I am unable to debug it (with cffi I successfully used gdb
>>>>>>> already)  -> if you can I will be really interested.
>>>>>>>
>>>>>>
>>>>>> No thats fine. You just gdb python and run the code in there. Can be
>>>>>> messy if the bug is in the interface (very unusual) but fine for the
>>>>>> underlying C code. Hence my use of this approach for rapid prototyping.
>>>>>>
>>>>>>
>>>>>>  - Heavier dependancy than cffi-python (I guess it is arguable).
>>>>>>>
>>>>>>
>>>>>> I think SWIG is self contained but could be wrong.
>>>>>>
>>>>>>
>>>>>>    I use quite a lot of machines (5-6) without sudo access where is
>>>>>>> very old Swig.
>>>>>>>
>>>>>>
>>>>>> It is easy to download and compile locally without sudo. You just
>>>>>> need it on your path to run.
>>>>>>
>>>>>>
>>>>>>    I can install cffi very easily. Actually I wrote installation
>>>>>>> script for it (True it requires Python headers and libffi. Hopefully the
>>>>>>> libffi dependancy
>>>>>>> disappears in future.)
>>>>>>>
>>>>>>> To conclude, the main objective against SWIG is,
>>>>>>> that for developing interfaces (which changes quickly) SWIG is a
>>>>>>> heavy choice for me.
>>>>>>> With cffi-python it seems to me that I can work much faster.
>>>>>>>
>>>>>>
>>>>>> I think if you are building a clean C API then it is easy to switch
>>>>>> to SWIG at a later date if required anyway. I could use SWIG for idlak and
>>>>>> we could compare and then go with whichever the community thought best in
>>>>>> the long run.
>>>>>>
>>>>>> At some point I'll check in an example SWIG wrapping into idlak for
>>>>>> people to look at.
>>>>>>
>>>>>> All the very best
>>>>>>
>>>>>>
>>>>>> M.
>>>>>>
>>>>>>
>>>>>>> Best
>>>>>>>
>>>>>>> Ondra
>>>>>>>
>>>>>>> PS: With cffi-python the docs is quite good but the included demos
>>>>>>> gives you better idea how it can be used:
>>>>>>> https://bitbucket.org/cffi/cffi/src/ab9e53ebcfb97eb8bee8d15cac57c3
>>>>>>> f41d42f6f4/demo?at=default
>>>>>>> PS2: I would like to learn how to use SWIG effectively. I was just
>>>>>>> incapable of doing it so far :)
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 16, 2013 at 2:54 PM, Matthew Aylett <
>>>>>>> mat...@gm...> wrote:
>>>>>>>       Hi
>>>>>>> No prefer to be involved because will want to wrap Idlak too and
>>>>>>> will need to do it the same way.
>>>>>>>
>>>>>>> I very much agree that if we wrap code it should be round a clear C
>>>>>>> API. As such how it's wrapped becomes less of an issue. Wrapping C++ tends
>>>>>>> to make
>>>>>>> memory management less explicit.
>>>>>>>
>>>>>>> Doing this is most problematic if 1. you want to return anything
>>>>>>> other than values or 2. if you need callbacks.
>>>>>>>
>>>>>>> On returning things like char * for example you need to decide on a
>>>>>>> standard approach. What I do is make sure there is a structure or class
>>>>>>> which manages
>>>>>>> the memory, then have a formal python function to create it into a
>>>>>>> python pointer and formally delete it when done. Then use C API calls to
>>>>>>> access any
>>>>>>> days.
>>>>>>>
>>>>>>> For callbacks the approach is more problematic because of things
>>>>>>> like the Global Lock in Python.
>>>>>>>
>>>>>>> If you want to write the callback in python you end up with Python
>>>>>>> calls C calls Python returns to C returns to Python. However I'm guessing
>>>>>>> we don't use
>>>>>>> callbacks much in kaldi (although if you write a realtime decoder
>>>>>>> that might well change).
>>>>>>>
>>>>>>> Funnily enough Ondrej, your point about it all being in C as a
>>>>>>> positive is not so much for me. Me experience of SWIG has been very good
>>>>>>> (once you get the
>>>>>>> makefiles to work). For standard C API just running it over the
>>>>>>> header file is enough to generate everything you need. (Care required for 1
>>>>>>> and yes SWIG
>>>>>>> specific code required for 2.) So you don't generally need to know
>>>>>>> anything about the SWIG language to wrap 99% of everything.
>>>>>>>
>>>>>>> Because it produces python versions of the functions you can use
>>>>>>> command line completion (which I can't generally live without in python).
>>>>>>>
>>>>>>> However the best thing about it is that wrapping Java, C# is just as
>>>>>>> easy (with the caveat about 2. I had to write java specific code for
>>>>>>> callbacks in
>>>>>>> particular to support the Android compiler.)
>>>>>>>
>>>>>>> However 90% of the work is making the C style API so if thats done
>>>>>>> its easy enough to change to SWIG if you want to wrap Java etc.
>>>>>>>
>>>>>>> I can see where you are coming from but in my experience when you
>>>>>>> wrap code it precisely because the user DOESN'T know C. Also the SWIG
>>>>>>> wrapping is so
>>>>>>> fast an easy I have used it often in development to try out C
>>>>>>> routines and code and hacking pything for all the IO display stuff.
>>>>>>>
>>>>>>> So for SWIG an example my be the following in the header:
>>>>>>>
>>>>>>> typedef struct CPRC_buf CPRC_buf;
>>>>>>>
>>>>>>> /** Create a buffer. (if max_sz == -1 unlimited size)*/
>>>>>>> extern CPRC_buf * CPRC_buf_new(int min_sz, int max_sz);
>>>>>>> /** Remove a buffer and its associated memory. */
>>>>>>> extern void CPRC_buf_delete(CPRC_buf * buf);
>>>>>>> /** Add a string emsg to the buffer. */
>>>>>>> extern void CPRC_buf_add(CPRC_buf *buf, const char * emsg);
>>>>>>> /** Empty the buffer. */
>>>>>>> extern const char * CPRC_buf_clear(CPRC_buf * buf);
>>>>>>> /** Return a pointer to the contents of the buffer. */
>>>>>>> extern const char * CPRC_buf_get(CPRC_buf * buf);
>>>>>>>
>>>>>>>
>>>>>>> and the .i file:
>>>>>>>
>>>>>>> /*file: mymod.i */
>>>>>>> %feature("autodoc", "1");
>>>>>>>
>>>>>>> %module mymod
>>>>>>> %{
>>>>>>> extern "C" {
>>>>>>> #include "mymod.h"
>>>>>>> }
>>>>>>> %}
>>>>>>>
>>>>>>>
>>>>>>> extern "C" {
>>>>>>> #include "mymod.h"
>>>>>>> }
>>>>>>> %include "mymod.h"
>>>>>>>
>>>>>>>
>>>>>>> Thats it. Add another function to the header it just automatically
>>>>>>> wraps it.
>>>>>>>
>>>>>>> On saying all this the big issue is still the vanilla C API and
>>>>>>> consistency. I just think you may have been a bit quick to dismiss SWIG.
>>>>>>>
>>>>>>> However I have a very poor grasp of most of the code you are
>>>>>>> discussing so take my comments with that in mind.
>>>>>>>
>>>>>>> Very best
>>>>>>>
>>>>>>> Matthew
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 16, 2013 at 9:39 AM, Vassil Panayotov <
>>>>>>> vas...@gm...> wrote:
>>>>>>>       Hi,
>>>>>>>
>>>>>>>       On Tue, Jul 16, 2013 at 1:34 AM, ondrej platek <
>>>>>>> ond...@se...> wrote:
>>>>>>>       > I am CCopying Vassil, because he might be interested in the
>>>>>>> Python/C
>>>>>>>       > interface of his online decoder.
>>>>>>>
>>>>>>> Ondra, thanks for adding me.
>>>>>>>
>>>>>>> I think I was somewhat confused at first about the scope of your
>>>>>>> project.
>>>>>>> I thought, that you are working on a fine grained Python API, which
>>>>>>> gives direct access to the core classes in the online decoder. I only
>>>>>>> glanced through your code, but by looking at KaldiDecoderWrapper it
>>>>>>> seems to me it's more like the user gets access to a commonly used
>>>>>>> decoder configuration - i.e. KaldiDecoderWrapper::Setup() is
>>>>>>> basically
>>>>>>> the same as the main() functions of the sample binaries in
>>>>>>> onlinebin/.
>>>>>>> It seems to me, that in that regard, the functionality provided by
>>>>>>> your code is very similar to that of Tanel Alumae's gst-plugin
>>>>>>> (GStreamer has Python bindings). Just an observation - not saying it
>>>>>>> as if it's something bad...
>>>>>>>
>>>>>>> By the way I would prefer to keep the core online decoder code as
>>>>>>> compact as possible, and I think the code that is used only by the
>>>>>>> extensions should be placed in their respective directories. I think
>>>>>>> OnlineBlockSource should be placed in separate .h/.cc files, like
>>>>>>> this
>>>>>>> is the case with GstBufferSource (in gst-plugin/gst-audio-source.h).
>>>>>>>
>>>>>>> PS: Mathew, I know you are working mostly on Idlak, but since you
>>>>>>> said
>>>>>>> you have plenty of experience with wrapping code for interfacing with
>>>>>>> Python (and I don't have such experience) I decided against removing
>>>>>>> you from this discussion, that I realize may not be very interesting
>>>>>>> to you.
>>>>>>>
>>>>>>> Vassil
>>>>>>>
>>>>>>> > See the second half: Concrete example.
>>>>>>> >
>>>>>>> > What is CFFI?
>>>>>>> > There is a CFFI library known for interfacing C to list.
>>>>>>> > However, there is also a quite new Python library completely
>>>>>>> unrelated to
>>>>>>> > the lisp one.
>>>>>>> > http://cffi.readthedocs.org/en/release-0.6/
>>>>>>> > I liked it a lot since it interfaces the languages Python and C
>>>>>>> without any
>>>>>>> > intermediate language
>>>>>>> > and it does it really elegant way.
>>>>>>> >
>>>>>>> > I used swig several times and is is a way, but not for me after
>>>>>>> trying
>>>>>>> > python-cffi.
>>>>>>> > Mainly because swig intermediate language it is not standard
>>>>>>> language with
>>>>>>> > ready tools for debugging, lints and other helper stuff for
>>>>>>> developing.
>>>>>>> > Debugging the language interface is not really fun.
>>>>>>> >
>>>>>>> > I have to admit I am highly bias to python-cffi against swig.
>>>>>>> > Mainly, because I am able to write things in Python-cffi very
>>>>>>> easily which I
>>>>>>> > was unable to do in Swig.
>>>>>>> >
>>>>>>> > I wrap the C++ interface by the C interface and the using the
>>>>>>> python-cffi I
>>>>>>> > access the C code from Python (and vice versa).
>>>>>>> > I highly recommend to restrict the C++ to C interface, because the
>>>>>>> > simplification with
>>>>>>> >
>>>>>>> > a) NO function overloading/virtual function tables (forced by the
>>>>>>> C syntax)
>>>>>>> > b) NO problems with mangling (if you define correct C interface)
>>>>>>> >
>>>>>>> > pays back very early.
>>>>>>> >
>>>>>>> > Note, that python-cffi is not able to interface C++ code and I am
>>>>>>> quite glad
>>>>>>> > for it.
>>>>>>> > I guess it pays off use as simple as possible interface between any
>>>>>>> > languages also for Swig.
>>>>>>> >
>>>>>>> > =================
>>>>>>> > Concrete example:
>>>>>>> >
>>>>>>> > Last week I was working on C interface for online-gmm-faster
>>>>>>> decoder.
>>>>>>> > I wrapped the functionality of the binary
>>>>>>> > kaldi/trunk/src/online-gmm-decode-faster to C++ class
>>>>>>> KaldiDecoderWrapper
>>>>>>> > In addition I added C wrapper to the C++ class, so it supports C
>>>>>>> linkage.
>>>>>>> >
>>>>>>> > Both the C and C++ interface can be found at
>>>>>>> > kaldi/src/pykaldi/online-python-gmm-decode-faster.h
>>>>>>> > either in sandbox/oplatek2 or at github
>>>>>>> > (concretaly at :
>>>>>>> > https://github.com/oplatek/pykaldi/blob/master/src/
>>>>>>> pykaldi/online-python-gmm-decode-faster.h)
>>>>>>> >
>>>>>>> > How the python-cffi is used against the C linkage can be seen at
>>>>>>> > OnlineDecoder:
>>>>>>> > https://github.com/oplatek/pykaldi/blob/master/src/
>>>>>>> pykaldi/decoders/kaldi_decoders.py#L50
>>>>>>> >
>>>>>>> > How to try the demo for OnlineDecoder which works for me under
>>>>>>> Linux is
>>>>>>> > described at:
>>>>>>> > https://github.com/oplatek/pykaldi/tree/master/src/
>>>>>>> pykaldi/binutils#how-to-run-the-demo
>>>>>>> >
>>>>>>> > Let me know if you have problems running the demo (I did not test
>>>>>>> it well,
>>>>>>> > but I wanted to reply with something real).
>>>>>>> >
>>>>>>> >
>>>>>>> > PS: Thanks Vassil for updating the online-audio interface. The
>>>>>>> Read function
>>>>>>> > without timetout makes better sense to me.
>>>>>>> >
>>>>>>> >
>>>>>>> > On Mon, Jul 15, 2013 at 9:22 PM, Daniel Povey <dp...@gm...>
>>>>>>> wrote:
>>>>>>> >>
>>>>>>> >> Attaching Ondrej, he may have some comments.
>>>>>>> >> Dan
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> On Mon, Jul 15, 2013 at 3:22 AM, Matthew Aylett <
>>>>>>> mat...@gm...>
>>>>>>> >> wrote:
>>>>>>> >> > Hi
>>>>>>> >> >
>>>>>>> >> > CFFI -
>>>>>>> >> > Common Foreign Function Interface, purports to be a portable
>>>>>>> foreign
>>>>>>> >> > function interface for Common Lisp.
>>>>>>> >> >
>>>>>>> >> > Eh?
>>>>>>> >> >
>>>>>>> >> > I have quite  lot of experience wrapping for Python. My advice
>>>>>>> is:
>>>>>>> >> >
>>>>>>> >> > 1. Define a C API for wrapping. Avoid blanking wrapping of
>>>>>>> headers with
>>>>>>> >> > something like SWIG and define and justify which functions and
>>>>>>> >> > structures
>>>>>>> >> > should be wrapped. Do not wrap C++ objects (fine for dev work)
>>>>>>> but very
>>>>>>> >> > hard
>>>>>>> >> > to control in a release environment if we ever want to release
>>>>>>> kaldi as
>>>>>>> >> > a
>>>>>>> >> > binary library. In addition C API becomes basic API for such a
>>>>>>> library
>>>>>>> >> > avoiding C++ name mangling issues. Same API is then used to
>>>>>>> wrap for C#
>>>>>>> >> > Java
>>>>>>> >> > etc.
>>>>>>> >> >
>>>>>>> >> > 2. Use something like SWIG to automatically generate
>>>>>>> python/C#/Java API
>>>>>>> >> > code
>>>>>>> >> > from the C API.
>>>>>>> >> >
>>>>>>> >> > Of course when you find a stable way to do something you just
>>>>>>> end up
>>>>>>> >> > sticking with it so its perfectly possible there are better
>>>>>>> ways and all
>>>>>>> >> > this has been explored etc. (Arnab mentioned they had already
>>>>>>> looked at
>>>>>>> >> > SWIG
>>>>>>> >> > but perhaps only in the context of wrapping already written
>>>>>>> headers not
>>>>>>> >> > based on writing a formal API header.) I'm guessing the CFFI is
>>>>>>> more or
>>>>>>> >> > less
>>>>>>> >> > 1. above. Anyway happy to discuss my experiences with Ondrej if
>>>>>>> its any
>>>>>>> >> > help.
>>>>>>> >> >
>>>>>>> >> > Best
>>>>>>> >> >
>>>>>>> >> > M.
>>>>>>> >>
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > On Mon, Jul 15, 2013 at 6:27 AM, Daniel Povey <dp...@gm...>
>>>>>>> wrote:
>>>>>>> >> >>
>>>>>>> >> >> Hi everyone,
>>>>>>> >> >> I have been a bit lax in the last few weeks in sending out
>>>>>>> updates.
>>>>>>> >> >>
>>>>>>> >> >> People might have noticed a change in the build process.  We
>>>>>>> >> >> reorganized the setup to use dynamic libraries (so Kaldi does
>>>>>>> not take
>>>>>>> >> >> up so much space on disk) and to consolidate the shared parts
>>>>>>> of the
>>>>>>> >> >> Makefiles.  Thanks to Jan Trmal and Ondrej Platek who did most
>>>>>>> of the
>>>>>>> >> >> work.
>>>>>>> >> >>
>>>>>>> >> >> There have been some contributions from new people, regarding
>>>>>>> various
>>>>>>> >> >> ways to call Kaldi from other languages and frameworks:
>>>>>>> >> >>
>>>>>>> >> >>    - Tanel Alumae has created an example Kaldi plugin for the
>>>>>>> >> >> GStreamer framework (see http://en.wikipedia.org/wiki/
>>>>>>> GStreamer for
>>>>>>> >> >> what that is).  see src/gst-plugin/
>>>>>>> >> >>    - Danijel Korzinek has written some Java code that can
>>>>>>> function as
>>>>>>> >> >> a source of audio for the online decoder (there is some info
>>>>>>> about
>>>>>>> >> >> this at http://kaldi.sourceforge.net/online_programs.html)
>>>>>>> >> >>    - Ondrej Platek is currently working on ways to call Kaldi
>>>>>>> from
>>>>>>> >> >> Python (this is not yet merged to the trunk, it's still in
>>>>>>> >> >> ^/sandbox/oplatek).  It's based on "CFFI" (the Common Foreign
>>>>>>> Function
>>>>>>> >> >> Interface).
>>>>>>> >> >>
>>>>>>> >> >> Vassil Panayotov has been helping to test these additions and
>>>>>>> has been
>>>>>>> >> >> improving the online-decoding code.
>>>>>>> >> >>
>>>>>>> >> >> I have added a recipe for the Fisher English database.
>>>>>>> >> >>
>>>>>>> >> >> Gilles Boulianne improved the (time and memory) efficiency of
>>>>>>> the
>>>>>>> >> >> arpa2fst program.
>>>>>>> >> >>
>>>>>>> >> >> Karel Vesely continues to improve his neural-network training
>>>>>>> setup
>>>>>>> >> >> and the associated recipes.
>>>>>>> >> >>
>>>>>>> >> >> I had been hoping by now to have already committed changes
>>>>>>> regarding
>>>>>>> >> >> the use of ReLUs (rectified linear units) to my neural-network
>>>>>>> setup,
>>>>>>> >> >> but it's not ready yet.  ReLUs seemed to be helpful on RM and
>>>>>>> WSJ-84,
>>>>>>> >> >> but when I ran the recipe on the WSJ full SI284 data I didn't
>>>>>>> see a
>>>>>>> >> >> clear improvement.  Right now I am working on larger changes
>>>>>>> to that
>>>>>>> >> >> setup, including a rewrite of the scripts that's intended to
>>>>>>> make the
>>>>>>> >> >> training more efficient, but it will probably be at least a
>>>>>>> few weeks
>>>>>>> >> >> before I can check it in.  Also a CUDA-enabled version of my
>>>>>>> parallel
>>>>>>> >> >> neural network training setup is in the works (i.e. training on
>>>>>>> >> >> multiple CUDA cards) but this will be at least a couple
>>>>>>> months.  I did
>>>>>>> >> >> not get time (as I had hoped I would) to add any speaker-id
>>>>>>> stuff to
>>>>>>> >> >> Kaldi.
>>>>>>> >> >>
>>>>>>> >> >> Dan
>>>>>>> >> >>
>>>>>>> >> >> --
>>>>>>> >> >>
>>>>>>> >> >> ---
>>>>>>> >> >> You received this message because you are subscribed to the
>>>>>>> Google
>>>>>>> >> >> Groups
>>>>>>> >> >> "but10" group.
>>>>>>> >> >> To unsubscribe from this group and stop receiving emails from
>>>>>>> it, send
>>>>>>> >> >> an
>>>>>>> >> >> email to but...@go....
>>>>>>> >> >> For more options, visit https://groups.google.com/
>>>>>>> groups/opt_out.
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> >
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>