Microphone starts recording immediately

[Xasin]

I was playing around with the CMU Sphinx microphone, and I noticed something a little strange.
Whenever I use it to record something, it got the wrong audio - I am using the same code to write into a file as the example given, apart from a few tweaks to give me variable length recording time:

`rm /tmp/sphinxbuf.raw`
   File.open '/tmp/sphinxbuf.raw', 'wb' do |file|
   mic.record do
      FFI::MemoryPointer.new(:int16, 2048) do |bfr|
         while Time.now() - last_s_press < 1
            samp_count = mic.read_audio(bfr, 2048);
            file.write bfr.get_bytes(0, samp_count*2);

            sleep 0.1;
         end
      end
   end
end

This code gets executed after a slight delay, while the "mic" Instance is created right after starting the program.
The audio file that results from this seems to contain the audio that the mic captures right after initialization, not after the 'record' block begins.

It also seems like recording continues even after leaving the record block, suggesting that the 'stop_recording' call does not actually stop recording.

I believe this is due to the Linux audio system - it might immediately start queueing audio data after the audio device is opened, regardless of the call to "start recording"

Lastly, the 'close device' call is also a little dysfunctional, as it only throws the following error:

/var/lib/gems/2.3.0/gems/pocketsphinx-ruby-0.4.0/lib/pocketsphinx/api/call_helpers.rb:9:in `block in api_call': undefined method `<' for nil:NilClass (NoMethodError)
	from /var/lib/gems/2.3.0/gems/pocketsphinx-ruby-0.4.0/lib/pocketsphinx/api/call_helpers.rb:8:in `tap'
	from /var/lib/gems/2.3.0/gems/pocketsphinx-ruby-0.4.0/lib/pocketsphinx/api/call_helpers.rb:8:in `api_call'
	from /var/lib/gems/2.3.0/gems/pocketsphinx-ruby-0.4.0/lib/pocketsphinx/microphone.rb:68:in `close_device'

I am running Ruby 2.3.3p222, with a recent and self-compiled Pocketsphinx version (couldn't quite determine the version, the console commands are lacking a --version?)

This issue can easily be worked around by continuously polling and dumping unneeded data, but that strikes me as a little less elegant.