Menu
▾
▴
kaldi-users — Kaldi Users
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
|
Feb
|
Mar
(8) |
Apr
(4) |
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(7) |
May
(31) |
Jun
(40) |
Jul
(65) |
Aug
(37) |
Sep
(12) |
Oct
(57) |
Nov
(15) |
Dec
(35) |
| 2014 |
Jan
(3) |
Feb
(30) |
Mar
(57) |
Apr
(26) |
May
(49) |
Jun
(26) |
Jul
(63) |
Aug
(33) |
Sep
(20) |
Oct
(153) |
Nov
(62) |
Dec
(20) |
| 2015 |
Jan
(6) |
Feb
(21) |
Mar
(42) |
Apr
(33) |
May
(76) |
Jun
(102) |
Jul
(39) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Daniel P. <dp...@gm...> - 2013-12-19 07:33:29
|
There is I believe a Kaldi program 'fstminimizeencoded' that should not increase the number of states. Dan On Wed, Dec 18, 2013 at 11:31 PM, Lahiru Samarakoon <lah...@gm...>wrote: > Actually, I tried several decompositions of the G.fst, then to check my > decompositions I composed those back. The increase happened to the new > language model, not to the original model generated by the arpa2fst. > > > On Thu, Dec 19, 2013 at 3:25 PM, Daniel Povey <dp...@gm...> wrote: > >> BTW, because of the way the ARPA format works, a language-model FST >> should already be minimal or close to minimal. How much does its size get >> increased when you minimize? >> Dan >> >> >> >> On Wed, Dec 18, 2013 at 10:38 PM, Lahiru Samarakoon <lah...@gm...>wrote: >> >>> Thanks for the quick response. >>> >>> >>> On Thu, Dec 19, 2013 at 2:22 PM, Michael Riley <ri...@go...> wrote: >>> >>>> http://www.openfst.org/twiki/bin/view/FST/MinimizeDoc >>>> >>>> >>>> On Thu, Dec 19, 2013 at 1:13 AM, Lahiru Samarakoon <lah...@gm...>wrote: >>>> >>>>> >>>>> HI All, >>>>> >>>>> I have my own language model. When I minimize it, actually it >>>>> increases the number of states and arcs. >>>>> >>>>> How can this be possible? >>>>> I have created the LM in arpa format and used scripts from Kaldi to >>>>> create the G.fst. >>>>> >>>>> Thank you, >>>>> >>>>> Best Regards, >>>>> Lahiru >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>>> organizations don't have a clear picture of how application performance >>>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>>> your >>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>>> AppDynamics Pro! >>>>> >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Kaldi-users mailing list >>>>> Kal...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/kaldi-users >>>>> >>>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into >>> your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>> AppDynamics Pro! >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Kaldi-users mailing list >>> Kal...@li... >>> https://lists.sourceforge.net/lists/listinfo/kaldi-users >>> >>> >> > |
|
From: Lahiru S. <lah...@gm...> - 2013-12-19 07:31:34
|
Actually, I tried several decompositions of the G.fst, then to check my decompositions I composed those back. The increase happened to the new language model, not to the original model generated by the arpa2fst. On Thu, Dec 19, 2013 at 3:25 PM, Daniel Povey <dp...@gm...> wrote: > BTW, because of the way the ARPA format works, a language-model FST should > already be minimal or close to minimal. How much does its size get > increased when you minimize? > Dan > > > > On Wed, Dec 18, 2013 at 10:38 PM, Lahiru Samarakoon <lah...@gm...>wrote: > >> Thanks for the quick response. >> >> >> On Thu, Dec 19, 2013 at 2:22 PM, Michael Riley <ri...@go...> wrote: >> >>> http://www.openfst.org/twiki/bin/view/FST/MinimizeDoc >>> >>> >>> On Thu, Dec 19, 2013 at 1:13 AM, Lahiru Samarakoon <lah...@gm...>wrote: >>> >>>> >>>> HI All, >>>> >>>> I have my own language model. When I minimize it, actually it increases >>>> the number of states and arcs. >>>> >>>> How can this be possible? >>>> I have created the LM in arpa format and used scripts from Kaldi to >>>> create the G.fst. >>>> >>>> Thank you, >>>> >>>> Best Regards, >>>> Lahiru >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Rapidly troubleshoot problems before they affect your business. Most IT >>>> organizations don't have a clear picture of how application performance >>>> affects their revenue. With AppDynamics, you get 100% visibility into >>>> your >>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>>> AppDynamics Pro! >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Kaldi-users mailing list >>>> Kal...@li... >>>> https://lists.sourceforge.net/lists/listinfo/kaldi-users >>>> >>>> >>> >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >> Pro! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Kaldi-users mailing list >> Kal...@li... >> https://lists.sourceforge.net/lists/listinfo/kaldi-users >> >> > |
|
From: Daniel P. <dp...@gm...> - 2013-12-19 07:25:25
|
BTW, because of the way the ARPA format works, a language-model FST should already be minimal or close to minimal. How much does its size get increased when you minimize? Dan On Wed, Dec 18, 2013 at 10:38 PM, Lahiru Samarakoon <lah...@gm...>wrote: > Thanks for the quick response. > > > On Thu, Dec 19, 2013 at 2:22 PM, Michael Riley <ri...@go...> wrote: > >> http://www.openfst.org/twiki/bin/view/FST/MinimizeDoc >> >> >> On Thu, Dec 19, 2013 at 1:13 AM, Lahiru Samarakoon <lah...@gm...>wrote: >> >>> >>> HI All, >>> >>> I have my own language model. When I minimize it, actually it increases >>> the number of states and arcs. >>> >>> How can this be possible? >>> I have created the LM in arpa format and used scripts from Kaldi to >>> create the G.fst. >>> >>> Thank you, >>> >>> Best Regards, >>> Lahiru >>> >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. Most IT >>> organizations don't have a clear picture of how application performance >>> affects their revenue. With AppDynamics, you get 100% visibility into >>> your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>> AppDynamics Pro! >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Kaldi-users mailing list >>> Kal...@li... >>> https://lists.sourceforge.net/lists/listinfo/kaldi-users >>> >>> >> > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > > |
|
From: Lahiru S. <lah...@gm...> - 2013-12-19 06:38:52
|
Thanks for the quick response. On Thu, Dec 19, 2013 at 2:22 PM, Michael Riley <ri...@go...> wrote: > http://www.openfst.org/twiki/bin/view/FST/MinimizeDoc > > > On Thu, Dec 19, 2013 at 1:13 AM, Lahiru Samarakoon <lah...@gm...>wrote: > >> >> HI All, >> >> I have my own language model. When I minimize it, actually it increases >> the number of states and arcs. >> >> How can this be possible? >> I have created the LM in arpa format and used scripts from Kaldi to >> create the G.fst. >> >> Thank you, >> >> Best Regards, >> Lahiru >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >> Pro! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Kaldi-users mailing list >> Kal...@li... >> https://lists.sourceforge.net/lists/listinfo/kaldi-users >> >> > |
|
From: Michael R. <ri...@go...> - 2013-12-19 06:23:08
|
http://www.openfst.org/twiki/bin/view/FST/MinimizeDoc On Thu, Dec 19, 2013 at 1:13 AM, Lahiru Samarakoon <lah...@gm...>wrote: > > HI All, > > I have my own language model. When I minimize it, actually it increases > the number of states and arcs. > > How can this be possible? > I have created the LM in arpa format and used scripts from Kaldi to create > the G.fst. > > Thank you, > > Best Regards, > Lahiru > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > > |
|
From: Lahiru S. <lah...@gm...> - 2013-12-19 06:13:56
|
HI All, I have my own language model. When I minimize it, actually it increases the number of states and arcs. How can this be possible? I have created the LM in arpa format and used scripts from Kaldi to create the G.fst. Thank you, Best Regards, Lahiru |
|
From: Daniel P. <dp...@gm...> - 2013-12-12 22:39:17
|
You won't be able to reproduce the behavior of "sp" in Kaldi, as it is "invisible" to context. It's not at all recommended to try to combine Kaldi and HTK systems. Dan On Thu, Dec 12, 2013 at 8:43 AM, Nagendra Goel <nag...@go...>wrote: > It is possible to modify L.fst to introduce additional phones other than > "sil". The loop going back to the new word is under your control. However > its not clear if that will give any true advantage. "sp" was introduced in > HTK to handle databases such as switchboard and there may be some advantage > to doing this if you have optional noise phones that you want to keep > separate from sil. > > Nagendra > > > On Thu, Dec 12, 2013 at 4:57 AM, dophist <do...@gm...> wrote: > >> Hi all, Daniel, >> >> I've recently worked on Kaldi toolkit, got a problem with sp model. >> >> In a typical HTK system, 'sil' and 'sp' are conceptional different, even >> in terms of number of states, 'sil' tends to have 3-5 states, whereas 'sp' >> has 1. >> >> In Kaldi, if I get it right, recipes introduce a single concept called >> 'optional silence', which can occur at the beginning/between-words/end of >> an utterance. This "optional silence" plays the role of both 'sp' and >> 'sil' in HTK. >> >> is it possible to train a Kaldi model with seperate sp and sil model? I >> do this mainly because I have another system that assumes sp and sil are >> different, and I want kaldi to provide acoustic model for that system. >> >> Now one solution I can think of, is to modify the default L.fst structure >> in Kaldi (make_lexicon_fst.sh script), such as substituting sil with sp on >> word_end_phone branching arc(sil-state/loop-state branching), but I'm not >> sure if this breaks any assumption of other parts of the recipe. >> >> Best regards, >> Jiayu >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >> Pro! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Kaldi-users mailing list >> Kal...@li... >> https://lists.sourceforge.net/lists/listinfo/kaldi-users >> >> > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > > |
|
From: Nagendra G. <nag...@go...> - 2013-12-12 13:43:08
|
It is possible to modify L.fst to introduce additional phones other than "sil". The loop going back to the new word is under your control. However its not clear if that will give any true advantage. "sp" was introduced in HTK to handle databases such as switchboard and there may be some advantage to doing this if you have optional noise phones that you want to keep separate from sil. Nagendra On Thu, Dec 12, 2013 at 4:57 AM, dophist <do...@gm...> wrote: > Hi all, Daniel, > > I've recently worked on Kaldi toolkit, got a problem with sp model. > > In a typical HTK system, 'sil' and 'sp' are conceptional different, even > in terms of number of states, 'sil' tends to have 3-5 states, whereas 'sp' > has 1. > > In Kaldi, if I get it right, recipes introduce a single concept called > 'optional silence', which can occur at the beginning/between-words/end of > an utterance. This "optional silence" plays the role of both 'sp' and > 'sil' in HTK. > > is it possible to train a Kaldi model with seperate sp and sil model? I do > this mainly because I have another system that assumes sp and sil are > different, and I want kaldi to provide acoustic model for that system. > > Now one solution I can think of, is to modify the default L.fst structure > in Kaldi (make_lexicon_fst.sh script), such as substituting sil with sp on > word_end_phone branching arc(sil-state/loop-state branching), but I'm not > sure if this breaks any assumption of other parts of the recipe. > > Best regards, > Jiayu > > > > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > > |
|
From: dophist <do...@gm...> - 2013-12-12 09:57:48
|
Hi all, Daniel, I've recently worked on Kaldi toolkit, got a problem with sp model. In a typical HTK system, 'sil' and 'sp' are conceptional different, even in terms of number of states, 'sil' tends to have 3-5 states, whereas 'sp' has 1. In Kaldi, if I get it right, recipes introduce a single concept called 'optional silence', which can occur at the beginning/between-words/end of an utterance. This "optional silence" plays the role of both 'sp' and 'sil' in HTK. is it possible to train a Kaldi model with seperate sp and sil model? I do this mainly because I have another system that assumes sp and sil are different, and I want kaldi to provide acoustic model for that system. Now one solution I can think of, is to modify the default L.fst structure in Kaldi (make_lexicon_fst.sh script), such as substituting sil with sp on word_end_phone branching arc(sil-state/loop-state branching), but I'm not sure if this breaks any assumption of other parts of the recipe. Best regards, Jiayu |
|
From: Jan T. <af...@ce...> - 2013-12-12 08:44:40
|
---------- Forwarded message ---------- From: "Jan Trmal" <jt...@gm...> Date: Dec 12, 2013 9:41 AM Subject: Re: [Kaldi-users] Using SWIG to wrap kaldi for python To: "ondrej platek" <ond...@gm...> Cc: "Dan Povey" <dp...@gm...>, "Danijel Korzinek" < da...@pj...>, "Arnab Ghoshal" <a.g...@ed...>, " kal...@li..." <kal...@li...> BTW, AFAIK SWIG has another nice feature -- from the interface files (*.i) it can generate wrappers for another languages, such as perl and java. Didn't do it personaly (only python), so there might be target-language-specific issues but I _think_ it should be pretty general. The slightly unpleasant property of SWIG was that the wrappers were "slightly on the wild side", I think it was because it was meant for pure C interfaces in the beginning. Y. On Dec 11, 2013 8:56 PM, "Ondrej Platek" <ond...@gm...> wrote: > 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. >>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> >> > >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > > |
|
From: Daniel P. <dp...@gm...> - 2013-12-12 00:30:34
|
Thanks a lot! I committed the change. I added you to the project so next time just go ahead and commit-- you have much more experience than me with this type of stuff so there is no reason to ask. Dan On Wed, Dec 11, 2013 at 7:05 PM, Nickolay V. Shmyrev <nsh...@gm...>wrote: > Dear Daniel > > Sounds great, there is a minor thing, dan2 branch recently had some > issues to build. I'm attaching the patch to fix the issues, the errors > are: > > First common issue is with int32: > > fgmm-global-gselect-to-post.cc: In function 'int main(int, char**)': > fgmm-global-gselect-to-post.cc:68: error: reference to 'int32' is > ambiguous > /home/shmyrev/dnn/dan2/tools/openfst/include/fst/types.h:30: error: > candidates are: typedef int32_t int32 > > Second issue is with CuMatrix: > > ../nnet2/kaldi-nnet2.a(nnet-component.o): In function > `kaldi::CuMatrixBase<double>::AddMatTp(double, > kaldi::CuMatrixBase<double> const&, kaldi::MatrixTransposeType, > kaldi::CuTpMatrix<double> const&, kaldi::MatrixTransposeType, double)': > /home/shmyrev/dnn/dan2/src/nnet2/../cudamatrix/cu-matrix.h:334: > undefined reference to > `kaldi::CuMatrix<double>::CuMatrix<double>(kaldi::CuTpMatrix<double> > const&, kaldi::MatrixTransposeType)' > ../nnet2/kaldi-nnet2.a(nnet-component.o): In function > `kaldi::CuMatrixBase<double>::AddTpMat(double, kaldi::CuTpMatrix<double> > const&, kaldi::MatrixTransposeType, kaldi::CuMatrixBase<double> const&, > kaldi::MatrixTransposeType, double)': > > > On 11/12/2013 at 13:45 -0500, Daniel Povey wrote: > > > > Everyone, > > > > > > I just merged the "sandbox/dan2" version of Kaldi back into the trunk, > > and deleted the sandbox/dan2 branch. > > If anyone has copies of ^/sandbox/dan2 they should switch them to > > point to the trunk by cd'ing to the top level of their repository and > > typing > > > > > > svn switch ^/trunk > > > > Dan > > |
|
From: Nickolay V. S. <nsh...@gm...> - 2013-12-12 00:06:01
|
Dear Daniel Sounds great, there is a minor thing, dan2 branch recently had some issues to build. I'm attaching the patch to fix the issues, the errors are: First common issue is with int32: fgmm-global-gselect-to-post.cc: In function 'int main(int, char**)': fgmm-global-gselect-to-post.cc:68: error: reference to 'int32' is ambiguous /home/shmyrev/dnn/dan2/tools/openfst/include/fst/types.h:30: error: candidates are: typedef int32_t int32 Second issue is with CuMatrix: ../nnet2/kaldi-nnet2.a(nnet-component.o): In function `kaldi::CuMatrixBase<double>::AddMatTp(double, kaldi::CuMatrixBase<double> const&, kaldi::MatrixTransposeType, kaldi::CuTpMatrix<double> const&, kaldi::MatrixTransposeType, double)': /home/shmyrev/dnn/dan2/src/nnet2/../cudamatrix/cu-matrix.h:334: undefined reference to `kaldi::CuMatrix<double>::CuMatrix<double>(kaldi::CuTpMatrix<double> const&, kaldi::MatrixTransposeType)' ../nnet2/kaldi-nnet2.a(nnet-component.o): In function `kaldi::CuMatrixBase<double>::AddTpMat(double, kaldi::CuTpMatrix<double> const&, kaldi::MatrixTransposeType, kaldi::CuMatrixBase<double> const&, kaldi::MatrixTransposeType, double)': On 11/12/2013 at 13:45 -0500, Daniel Povey wrote: > > Everyone, > > > I just merged the "sandbox/dan2" version of Kaldi back into the trunk, > and deleted the sandbox/dan2 branch. > If anyone has copies of ^/sandbox/dan2 they should switch them to > point to the trunk by cd'ing to the top level of their repository and > typing > > > svn switch ^/trunk > > Dan |
|
From: Ondrej P. <ond...@gm...> - 2013-12-11 19:56:14
|
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. >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> > >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> >> > |
|
From: Ondrej P. <ond...@gm...> - 2013-12-11 19:51:21
|
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/GStreamerfor >>>>>> >> >> 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. >>>>>> >> >> >>>>>> >> >> >>>>>> >> > >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>> >> > |
|
From: Daniel P. <dp...@gm...> - 2013-12-11 18:45:09
|
Everyone, I just merged the "sandbox/dan2" version of Kaldi back into the trunk, and deleted the sandbox/dan2 branch. If anyone has copies of ^/sandbox/dan2 they should switch them to point to the trunk by cd'ing to the top level of their repository and typing svn switch ^/trunk Dan |
|
From: Daniel P. <dp...@gm...> - 2013-12-11 18:27:40
|
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/GStreamerfor >>>>> >> >> 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 >>>>> . >>>>> >> >> >>>>> >> >> >>>>> >> > >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>>> >>>>> >>> >> > |
|
From: Daniel P. <dp...@gm...> - 2013-12-06 17:37:42
|
Ricky, I don't know if you have time to deal with this? I know you've
dealt with the patching of OpenFst before. This code could be put inside
an #ifdef so it will only be active if it's being compiled with gcc version
>= 4.1. (There's something like _GXX_VER or something like that, I think).
The patch should contain a comment saying it is a patch applied by the
Makefile in kaldi's tools/ directory, so that if someone has compilation
problems they will know where to look.
Dan
//int Incr() const { return ++count_; }
//int Decr() const { return --count_; }
int Incr() const { return __sync_add_and_fetch(&count_, 1); }
int Decr() const { return __sync_sub_and_fetch(&count_, 1); }
On Fri, Dec 6, 2013 at 11:27 AM, Gilles Boulianne
<gil...@cr...>wrote:
> Hi all,
>
> people who use Kaldi with multiple threads and experience crashes might be
> interested in this fix for OpenFst:
>
> http://www.openfst.org/twiki/bin/view/Forum/FstForum#Thread_safety
>
> Thanks to Yanqing Sun for submitting his problem with BigLmDecoder and
> testing the fix.
>
> Gilles Boulianne
> CRIM
> http://www.crim.ca
>
>
>
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-users mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-users
>
|
|
From: Gilles B. <gil...@cr...> - 2013-12-06 16:49:21
|
Hi all, people who use Kaldi with multiple threads and experience crashes might be interested in this fix for OpenFst: http://www.openfst.org/twiki/bin/view/Forum/FstForum#Thread_safety Thanks to Yanqing Sun for submitting his problem with BigLmDecoder and testing the fix. Gilles Boulianne CRIM http://www.crim.ca |
|
From: Karel V. <ive...@fi...> - 2013-12-03 22:19:32
|
Hi, I committed updated version of python scripts which is using buffering (no -u flag). Perhaps I put it there when I was developing the scripts while debugging and forgot to remove it later on. Many thanks for pointing it out. Karel Dne 2. 12. 2013 18:30, Daniel Povey napsal(a): > Thanks a lot for pointing this out. > Cc'ing Karel who maintains this part. > Dan > > > On Mon, Dec 2, 2013 at 3:39 AM, Josef Novak > <jos...@gm...> wrote: >> Hi, >> >> I have been digging around a bit in the dnn-related python scripts and had >> a question. >> >> All of the the python scripts are called with the -u flag. This means >> 'use unbuffered IO', which in turn means that every single byte is flushed >> to disk. >> >> I noticed this because utils/gen_rbm_init.py seemed to be taking an >> inordinate amount of time (1+ hours on the WSJ for each call to the script). >> >> In the case where all the data is on the local drive, and particularly if >> the local drive is an SSD, this would barely be noticeable - it is about 4x >> slower. But any kind of network latency massively magnifies the penalty. >> In my case, with a locally networked drive, the difference was: >> ---------------------------------------------------- >> #!/usr/bin/python -u: 1+ hours to write each N.rbm.init file >> #!/usr/bin/python: 10 seconds to write each N.rbm.init file >> ---------------------------------------------------- >> my understanding is that the -u flag also suppresses automatic newline >> conversion in 2.x - ensuring that Windows/Linux/OSX results would be >> equivalent/interoperable. This was the only reason I could come up with for >> why one might want to do this. However the potential time penalty for this >> is pretty massive, so I thought it worth pointing out. >> >> http://docs.python.org/2/using/cmdline.html#cmdoption-u >> >> http://docs.python.org/2/glossary.html#term-universal-newlines >> >> If there is some other motivation for using this flag I would also be >> curious to know what it might be. >> >> Best regards, >> Joe >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >> Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Kaldi-users mailing list >> Kal...@li... >> https://lists.sourceforge.net/lists/listinfo/kaldi-users >> |
|
From: Daniel P. <dp...@gm...> - 2013-12-02 17:30:38
|
Thanks a lot for pointing this out. Cc'ing Karel who maintains this part. Dan On Mon, Dec 2, 2013 at 3:39 AM, Josef Novak <jos...@gm...> wrote: > Hi, > > I have been digging around a bit in the dnn-related python scripts and had > a question. > > All of the the python scripts are called with the -u flag. This means > 'use unbuffered IO', which in turn means that every single byte is flushed > to disk. > > I noticed this because utils/gen_rbm_init.py seemed to be taking an > inordinate amount of time (1+ hours on the WSJ for each call to the script). > > In the case where all the data is on the local drive, and particularly if > the local drive is an SSD, this would barely be noticeable - it is about 4x > slower. But any kind of network latency massively magnifies the penalty. > In my case, with a locally networked drive, the difference was: > ---------------------------------------------------- > #!/usr/bin/python -u: 1+ hours to write each N.rbm.init file > #!/usr/bin/python: 10 seconds to write each N.rbm.init file > ---------------------------------------------------- > my understanding is that the -u flag also suppresses automatic newline > conversion in 2.x - ensuring that Windows/Linux/OSX results would be > equivalent/interoperable. This was the only reason I could come up with for > why one might want to do this. However the potential time penalty for this > is pretty massive, so I thought it worth pointing out. > > http://docs.python.org/2/using/cmdline.html#cmdoption-u > > http://docs.python.org/2/glossary.html#term-universal-newlines > > If there is some other motivation for using this flag I would also be > curious to know what it might be. > > Best regards, > Joe > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > |
|
From: Josef N. <jos...@gm...> - 2013-12-02 08:39:27
|
Hi, I have been digging around a bit in the dnn-related python scripts and had a question. All of the the python scripts are called with the -u flag. This means 'use unbuffered IO', which in turn means that every single byte is flushed to disk. I noticed this because utils/gen_rbm_init.py seemed to be taking an inordinate amount of time (1+ hours on the WSJ for each call to the script). In the case where all the data is on the local drive, and particularly if the local drive is an SSD, this would barely be noticeable - it is about 4x slower. But any kind of network latency massively magnifies the penalty. In my case, with a locally networked drive, the difference was: ---------------------------------------------------- #!/usr/bin/python -u: 1+ hours to write each N.rbm.init file #!/usr/bin/python: 10 seconds to write each N.rbm.init file ---------------------------------------------------- my understanding is that the -u flag also suppresses automatic newline conversion in 2.x - ensuring that Windows/Linux/OSX results would be equivalent/interoperable. This was the only reason I could come up with for why one might want to do this. However the potential time penalty for this is pretty massive, so I thought it worth pointing out. http://docs.python.org/2/using/cmdline.html#cmdoption-u http://docs.python.org/2/glossary.html#term-universal-newlines If there is some other motivation for using this flag I would also be curious to know what it might be. Best regards, Joe |
|
From: Daniel P. <dp...@gm...> - 2013-11-19 18:24:33
|
> Does anyone know how to extract word alignments for switchboard. > > I've found the following which I think should do the trick, but I haven't > been able to figure out what the start and end symbols are for the L.fst > that is built for the swbd lexicon. Or if I am using the right pronunciation > fst. > > " ali-to-phones 1.mdl ark:1.ali ark:- | \\\n" > " phones-to-prons L_align.fst 46 47 ark:- 1.tra ark:- | \\\n" > " prons-to-wordali ark:- \\\n" > " \"ark:ali-to-phones --write-lengths 1.mdl ark:1.ali ark:-|\" > ark:1.wali\n" > I think you may be using an example from some older scripts. The s5 scripts are the currently used ones, and there, a different mechanism is used to do word-alignment, based on position-dependent phones. See get_ctm.sh and get_ctm_train.sh Dan > > Any insights would be appreciated! > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Kaldi-users mailing list > Kal...@li... > https://lists.sourceforge.net/lists/listinfo/kaldi-users > |
|
From: Awni H. <aw...@st...> - 2013-11-19 18:05:37
|
Hi All,
Does anyone know how to extract word alignments for switchboard.
I've found the following which I think should do the trick, but I haven't
been able to figure out what the start and end symbols are for the L.fst
that is built for the swbd lexicon. Or if I am using the right
pronunciation fst.
" ali-to-phones 1.mdl ark:1.ali ark:- | \\\n"
" phones-to-prons L_align.fst 46 47 ark:- 1.tra ark:- | \\\n"
" prons-to-wordali ark:- \\\n"
" \"ark:ali-to-phones --write-lengths 1.mdl ark:1.ali ark:-|\"
ark:1.wali\n"
Any insights would be appreciated!
|
|
From: Vesely K. <ive...@fi...> - 2013-11-11 14:26:35
|
Hi Dan, some time ago we were running same experiments with Arnab for INTERSPEECH12 paper, the WER difference from DNN re-alignment was 0.4%. Training from GMM alignments (tri4a) : %WER 17.7 | 1831 21395 | 84.2 10.7 5.0 2.0 17.7 55.5 | exp/tri4a_dnn/decode_eval2000_sw1_fsh_tgpr/score_10/eval2000.ctm.swbd.filt.sys Training from scratch on alignment from previsous DNN : %WER 17.3 | 1831 21395 | 84.5 10.5 5.0 1.9 17.3 55.1 | exp/tri4a_dnn-iter2/decode_eval2000_sw1_fsh_tgpr/score_11/eval2000.ctm.swbd.filt.sys Maybe running the training on single GPU showif it is due to parallelization? More details: - training on 100h subset, single GPU - topology 4hid layers, 1200 sigmoid neurons each, 4234 outputs - the features were +/- 5 frame spliced fMLLR feature with LDA 360->350 dims, although the LDA was not important and replacing it with another hidden layer led to same improvement. - fMLLR features, alignments, tree from 'tri4a' GMM step: %WER 24.2 | 1831 21395 | 78.4 15.3 6.2 2.6 24.2 61.7 | exp/tri4a/decode_eval2000_sw1_fsh_tgpr/score_14/eval2000.ctm.swbd.filt.sys K. On 11/10/2013 05:23 AM, Daniel Povey wrote: > Karel, > [and cc'ing kaldi-users because I think people will be interested in > this discussion], > You mentioned that for your BABEL recipe you tried re-aligning the > data with the neural net system and training again from scratch. > > I tried this on a 100-hour subset of Switchboard and only got 0.1-0.2% > improvement; was this in the range of what you saw? > > For reference, here is the old CPU-based recipe (it's slightly worse, > probably because I used more machines in parallel, 16, versus > 8 in the GPU recipe): > > %WER 19.0 | 1831 21395 | 83.1 11.5 5.4 2.1 19.0 57.6 | > exp/nnet5a_cpu/decode_eval2000_sw1_fsh_tgpr/score_11/eval2000.ctm.swbd.filt.sys > %WER 19.5 | 1831 21395 | 82.8 11.8 5.4 2.3 19.5 57.5 | > exp/nnet5a_cpu/decode_eval2000_sw1_tg/score_11/eval2000.ctm.swbd.filt.sys > > Here is the GPU baseline: > > %WER 18.0 | 1831 21395 | 83.7 10.7 5.5 1.7 18.0 55.5 | > exp/nnet5a_gpu/decode_eval2000_sw1_fsh_tgpr/score_12/eval2000.ctm.swbd.filt.sys > %WER 18.6 | 1831 21395 | 83.4 11.2 5.4 2.0 18.6 56.6 | > exp/nnet5a_gpu/decode_eval2000_sw1_tg/score_11/eval2000.ctm.swbd.filt.sys > > And here is what I get when I realign the data with the system above, > and re-train the neural net from scratch using an otherwise similar > command: > > %WER 17.9 | 1831 21395 | 83.8 10.8 5.5 1.7 17.9 55.8 | > exp/nnet6a_gpu/decode_eval2000_sw1_fsh_tgpr/score_13/eval2000.ctm.swbd.filt.sys > %WER 18.4 | 1831 21395 | 83.6 11.4 5.0 2.1 18.4 56.1 | > exp/nnet6a_gpu/decode_eval2000_sw1_tg/score_11/eval2000.ctm.swbd.filt.sys > > Dan |
|
From: Daniel P. <dp...@gm...> - 2013-11-10 04:23:59
|
Karel, [and cc'ing kaldi-users because I think people will be interested in this discussion], You mentioned that for your BABEL recipe you tried re-aligning the data with the neural net system and training again from scratch. I tried this on a 100-hour subset of Switchboard and only got 0.1-0.2% improvement; was this in the range of what you saw? For reference, here is the old CPU-based recipe (it's slightly worse, probably because I used more machines in parallel, 16, versus 8 in the GPU recipe): %WER 19.0 | 1831 21395 | 83.1 11.5 5.4 2.1 19.0 57.6 | exp/nnet5a_cpu/decode_eval2000_sw1_fsh_tgpr/score_11/eval2000.ctm.swbd.filt.sys %WER 19.5 | 1831 21395 | 82.8 11.8 5.4 2.3 19.5 57.5 | exp/nnet5a_cpu/decode_eval2000_sw1_tg/score_11/eval2000.ctm.swbd.filt.sys Here is the GPU baseline: %WER 18.0 | 1831 21395 | 83.7 10.7 5.5 1.7 18.0 55.5 | exp/nnet5a_gpu/decode_eval2000_sw1_fsh_tgpr/score_12/eval2000.ctm.swbd.filt.sys %WER 18.6 | 1831 21395 | 83.4 11.2 5.4 2.0 18.6 56.6 | exp/nnet5a_gpu/decode_eval2000_sw1_tg/score_11/eval2000.ctm.swbd.filt.sys And here is what I get when I realign the data with the system above, and re-train the neural net from scratch using an otherwise similar command: %WER 17.9 | 1831 21395 | 83.8 10.8 5.5 1.7 17.9 55.8 | exp/nnet6a_gpu/decode_eval2000_sw1_fsh_tgpr/score_13/eval2000.ctm.swbd.filt.sys %WER 18.4 | 1831 21395 | 83.6 11.4 5.0 2.1 18.4 56.1 | exp/nnet6a_gpu/decode_eval2000_sw1_tg/score_11/eval2000.ctm.swbd.filt.sys Dan |
1 message has been excluded from this view by a project administrator.
