yunitate behavior: not ready for daylong files?

[alecristia]

I've tried to analyze a daylong file with yunitate. I suspect that yunitator runs out of memory ("std::bad_alloc"). Here is the full output:

[acristia@oberon DiViMe]$ vagrant ssh -c "yunitate.sh data/" wavs and transcriptions found ! Tests finished Starting /home/vagrant/launcher/yunitate.sh Extracting features for namibie_aiku_20170314_1.wav ... (MSG) [2] in SMILExtract : openSMILE starting! (MSG) [2] in SMILExtract : config file is: MED_2s_100ms_htk.conf (MSG) [2] in cComponentManager : successfully registered 96 component types. (MSG) [2] in cComponentManager : successfully finished createInstances (19 component instances were finalised, 1 data memories were finalised) (MSG) [2] in cComponentManager : starting single thread processing loop terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc ./extract-htk-vm2.sh: line 32: 11491 Aborted (core dumped) LD_LIBRARY_PATH=/home/vagrant/usr/local/lib $OPENSMILE -C $CONFIG_FILE -I $file -O $OUTPUT_DIR/${id}.htk -logfile extract-htk.log DONE! Extracting features for namibie_aiku_20170314_2.wav ... (MSG) [2] in SMILExtract : openSMILE starting! (MSG) [2] in SMILExtract : config file is: MED_2s_100ms_htk.conf (MSG) [2] in cComponentManager : successfully registered 96 component types. (MSG) [2] in cComponentManager : successfully finished createInstances (19 component instances were finalised, 1 data memories were finalised) (MSG) [2] in cComponentManager : starting single thread processing loop terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc ./extract-htk-vm2.sh: line 32: 11515 Aborted (core dumped) LD_LIBRARY_PATH=/home/vagrant/usr/local/lib $OPENSMILE -C $CONFIG_FILE -I $file -O $OUTPUT_DIR/${id}.htk -logfile extract-htk.log DONE! Traceback (most recent call last): File "yunified.py", line 159, in for feat in readHtk(INPUT_DIR+"/"+file, HTK_CHUNKSIZE, preSamples): File "G/coconut/fileutils/htk.py", line 19, in readHtk assert nSamples > 0, "nSamples needs to be > 0" AssertionError: nSamples needs to be > 0 ls: cannot access /vagrant/data//Yunitemp/.rttm.sorted: No such file or directory /home/vagrant/launcher/yunitate.sh finished running ls: cannot access /vagrant/data//Yunitemp/.rttm: No such file or directory Connection to 127.0.0.1 closed.

The Yunitemp folder did hold some features at a given point, but by the time the process is finished, it no longer exists.

[fmetze]

how much memory did you assign to the VM in the Vagrant file? what is the output of "vagrant ssh -c 'free'"?

[fmetze]

i made a change to the call to opensmile, i was able to process a daylong audio recording on my laptop. i had set the memory for the VM to 8GB, but it should also work with 4GB (the default)

[alecristia]

so sorry I was slow! I wanted to rerun it to make sure I hadn't done anything particularly silly. Just now I reproduced the same behavior I observed before. The VM was built with vbox.memory=6144. Here's the output of vagrant ssh -c 'free':

$ vagrant ssh -c 'free' total used free shared buffers cached Mem: 6112436 550172 5562264 436 24352 321188 -/+ buffers/cache: 204632 5907804 Swap: 0 0 0 Connection to 127.0.0.1 closed.

I changed the Vagrantfile to vbox.memory=8200, then did vagrant provision and vagrant up but a call to vagrant ssh -c "free" showed me this had not changed the memory. I guess it only updates packages and such. So I did vagrant destroy and vagrant up again, and checked that indeed the memory is larger. Then I re-launched the analysis of 1 daylong file that is about 15h long. It's still running but I already see the issue from before is no longer there. I notice THREE changes, though, so I'm not sure that increasing memory allocation is the only thing necessary:

1) there is a message "now at 0 of 54000" is absent from the previous error 2) a different config file is called 3) no memory error

LOG BEFORE REBUILDING VAGRANT

wavs and transcriptions found ! Tests finished Starting /home/vagrant/launcher/yunitate.sh Extracting features for namibie_aiku_20170314_1.wav ... (MSG) [2] in SMILExtract : openSMILE starting! (MSG) [2] in SMILExtract : config file is: MED_2s_100ms_htk.conf (MSG) [2] in cComponentManager : successfully registered 96 component types. (MSG) [2] in cComponentManager : successfully finished createInstances (19 component instances were finalised, 1 data memories were finalised) (MSG) [2] in cComponentManager : starting single thread processing loop terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc ./extract-htk-vm2.sh: line 32: 4173 Aborted (core dumped) LD_LIBRARY_PATH=/home/vagrant/usr/loc al/lib $OPENSMILE -C $CONFIG_FILE -I $file -O $OUTPUT_DIR/${id}.htk -logfile extract-htk.log DONE! Traceback (most recent call last): File "yunified.py", line 159, in for feat in readHtk(INPUT_DIR+"/"+file, HTK_CHUNKSIZE, preSamples): File "G/coconut/fileutils/htk.py", line 19, in readHtk assert nSamples > 0, "nSamples needs to be > 0" AssertionError: nSamples needs to be > 0 ls: cannot access /vagrant/data//Yunitemp/*.rttm.sorted: No such file or directory /home/vagrant/launcher/yunitate.sh finished running

LOG AFTER REBUILDING VAGRANT

wavs and transcriptions found ! Tests finished Starting /home/vagrant/launcher/yunitate.sh Extracting features for namibie_aiku_20170314_1.wav ... Now at 0 of 54000 ... (MSG) [2] in SMILExtract : openSMILE starting! (MSG) [2] in SMILExtract : config file is: /dev/fd/63 sox WARN wav: Length in output .wav header will be wrong since can't seek to fix it (MSG) [2] in cComponentManager : successfully registered 96 component types. (MSG) [2] in cComponentManager : successfully finished createInstances (19 component instances were finalised, 1 data memories were finalised) (MSG) [2] in cComponentManager : starting single thread processing loop (MSG) [2] in cComponentManager : Processing finished! System ran for 120023 ticks. Now at 1200 of 54000 ... (MSG) [2] in SMILExtract : openSMILE starting! (MSG) [2] in SMILExtract : config file is: /dev/fd/63 sox WARN wav: Length in output .wav header will be wrong since can't seek to fix it(MSG) [2] in cComponentManager : successfully registered 96 component types.

(MSG) [2] in cComponentManager : successfully finished createInstances (19 component instances were finalised, 1 data memories were finalised) (MSG) [2] in cComponentManager : starting single thread processing loop (MSG) [2] in cComponentManager : Processing finished! System ran for 120023 ticks.

[fmetze]

so, in short, this works now, not?

[alecristia]

yes!