soundplay_node.py crashes with "Too many open files" about audio_common HOT 13 CLOSED

There was a bug resulting in sound objects being removed from the cache but not properly closed, but that was fixed almost 4 years ago: 2657e6b

Obviously the node doesn't crash if you don't play files with it; can you provide a procedure or a script that reproduces the issue?

from audio_common.

@trainman419 Your fix is not enough, because in addition to python, gstreamer also has file descriptor till set_state(gst.STATE_NULL) is called.
(please note that in current code, __del__ method is not called.)
To reproduce this error, we just need to play sound many times. (approx. 400 times of 10 secs. audio)
You can find by top command, that soundplay_node.py has very high load and then crashes with too many open files.

from audio_common.

I have a collection of sound files in /usr/share/sounds/ubuntu/stereo that are part of the ubuntu-sounds package, so I was finally able to reproduce this by running:

sudo apt-get install ubuntu-sounds # just in case you don't have sound files
rosrun sound_play soundplay_node.py

and in a second terminal:

for ((i=0; i<21; i++)) ; do for f in /usr/share/sounds/ubuntu/stereo/* ; do rosrun sound_play play.py $f & sleep 0.1 ;  done ; done

(This would have been much faster and easier if you'd provided explicit reproduction instructions like this along with the initial pull request)

from audio_common.

@trainman419 Sorry for super late reply.

for ((i=0; i<21; i++)) ; do for f in /usr/share/sounds/ubuntu/stereo/* ; do rosrun sound_play play.py $f & sleep 0.1 ; done ; done

I think it does not reproduce the issue because in the script number of sound files is fixed.

Instead please test by running:

# Terminal 1
roslaunch sound_play soundplay_node.launch

# Terminal 2
for ((i=0; i<4000; i++)) ; do
  sox -n /tmp/output_$i.ogg synth 3 sin 440  # here new wav file is generated on every for loop
  rosrun sound_play play.py /tmp/output_$i.ogg & sleep 0.1
done

You will find that soundplay_node.py on terminal exits on failure. (I needed approx. 800 files to be played.)

from audio_common.

@trainman419 kindly ping to maintainer.

from audio_common.

@trainman419 ping

from audio_common.

@trainman419 ping

from audio_common.

It seems like your test is playing a huge number of files very quickly, and is therefore filling the cache faster than it can age out old entries. Is this really representative of your usage pattern?

from audio_common.

@trainman419 Yes, we create wave files using speech synthesis on each phrases and play them with sound_play. And I think we don't let robots speak so frequently, it should be just within normal usage...

from audio_common.

@trainman419 ping

from audio_common.

@trainman419 kindly ping

from audio_common.

It looks like you're playing 800 files different files in 80 seconds, the cache isn't aging out the old files quickly enough.

What sort of fix would you like to see here? Do you want a parameter to decrease the cache retention time? Limit the cache size so that old entries get pushed out sooner?

from audio_common.

@trainman419 Sorry for a late reply.
OK. I'll close this for now since other pull requests are blocked by this issue.
If I find any solution, I'll go back here.
Thank you very much, anyway!

from audio_common.