alumae/kaldi-gstreamer-server

Websocket closed when decode long audio files

kli017 opened this issue · 3 comments

Hello, I was doing decode with the kaldinnet2onlinedecoder. When I test some long audio such as the bill_gates-TED.mp3 or other audio longer than 1 min, Its always show "Audio sent, now sending EOS" and then the websocket closed. But when I checked the worker I found the decoder is still working just without sending the result to the client. I was wondering is there a limitation of the length of audio? How can I decode a long audio?
log

I had this similar issue, I was sending a long audio file matching rate of real time, however the result comes about 1/3 of real-time speed. After some debugging, I found out that server closes the socket after 40 seconds not receiving results from the decoder, and the decoder had already transcribed the entire audio in real time. The reason for the delay was caused by the sleep function in the post-processor.

So in my case removing sleep in the post-processor fixes the issue, but I'm still not sure why it's in some of the example settings. Maybe @alumae can shed some light on this? Much appreciate!

I had this similar issue, I was sending a long audio file matching rate of real time, however the result comes about 1/3 of real-time speed. After some debugging, I found out that server closes the socket after 40 seconds not receiving results from the decoder, and the decoder had already transcribed the entire audio in real time. The reason for the delay was caused by the sleep function in the post-processor.

So in my case removing sleep in the post-processor fixes the issue, but I'm still not sure why it's in some of the example settings. Maybe @alumae can shed some light on this? Much appreciate!

In the post_process method of worker.py, acquireing self.post_proessor_lock with timeout of 0.0 somehow blocked without raising TimeoutError, this jammed the pipeline.

I had this similar issue, I was sending a long audio file matching rate of real time, however the result comes about 1/3 of real-time speed. After some debugging, I found out that server closes the socket after 40 seconds not receiving results from the decoder, and the decoder had already transcribed the entire audio in real time. The reason for the delay was caused by the sleep function in the post-processor.
So in my case removing sleep in the post-processor fixes the issue, but I'm still not sure why it's in some of the example settings. Maybe @alumae can shed some light on this? Much appreciate!

In the post_process method of worker.py, acquireing self.post_proessor_lock with timeout of 0.0 somehow blocked without raising TimeoutError, this jammed the pipeline.

Acquiring tornado.locks.Lock with timeout=0.0 seems to block.
https://github.com/tornadoweb/tornado/blob/v4.5.3/tornado/locks.py#L389