[sound_play/scripts/soundplay_node.py] refactor and bugfix

[furushchev]

This Pull Request includes some features:

• bugfix: 'too many files open' (reported at soundplay_node.py crashes with "Too many open files" #75 )

  This bug occurs because soundplay_node holds file descriptor of all playing wave files even after finished playing.
  Also see new feature below.

• bugfix: repeating sound actually does not repeat. (reported at Sound.repeat() does not repeat the sound #65 )

  This bug occured because the existing code was dirty enough to be out of control player states.

• fix: permission of generated wav file (reported at sound_play: say command only works for first user on the robot #26 )

  This fix gives write permission to auto generated wave files.

• bugfix: play more than one sounds at a time (reported at Inconsistency in sound_play documentation and code (ros ticket #23) #23 )

  Now you can play multiple sounds simultaneously.

• new feature: specify prefix of files which are generated by sound_play node

  In existing node, prefix of files generated in /tmp are only fixed to sound_play.
  You can specify prefix by setting ros param.

• new feature: "caching timeout" parameter

  Though in existing code, all files were cached (see bugfix above), refactored code also holds some latest wave files in a short time for reusing.
  I added new parameter "cache_timeout". After playing audio and another "cache_timeout" seconds passed, the wave file is closed.
  Also I added service clear_cache for force clearing caches.

• new feature: "cache_saying_file" parameter

  If this parameter is set to "True", soundplay_node caches wave file generated automatically from festival for saying.

• [soundplay_node.launch] add parameters and documents for parameters

[jack-oquin]

Having made significant updates, there is nothing wrong with adding your own copyright line to the file, but you should not delete the old one.

[furushchev]

@jack-oquin Sorry I fixed. Actually, copy right is auto generated by my emacs.
Now added our rights to existing ones.

[furushchev]

@jack-oquin @trainman419
How do you think of this Pull Request?
Please give me advice if you have needed to be merged.

[jack-oquin]

I am not a maintainer of this repository, so merging is not my decision.

But, since you ask, it looks like you have fixed a lot of problems, but I find the extent of these changes rather worrisome, especially given the lack of unit tests for the affected package. That is especially a concern for Python modules: without reasonable test coverage, it is hard to ensure that all the code even compiles.

With packages I maintain, I like to see a small pull request for each individual bug fix, with a reference to the corresponding issue and a test case demonstrating the previous failure and the successful fix. That's an ideal, and I don't often get it, but that is what I try to do when modifying other people's packages.

[trainman419]

Sorry; this looked like a large set of changes and I haven't been able to find the time to sit down and give it a thorough review.

This it too large for me to review it and have a good idea of whether it fixes the issues or not.

All of the changes introduced by refactoring make it hard to understand which changes are just refactoring and which changes affect functionality.

Please break this into several pull requests; ideally separating the bug fixes, the refactoring and the new features into separate PRs.

[furushchev]

@trainman419 So how about splitting this pull request into some requests: first only refactoring, and then each bugfix and new features?

[trainman419]

Yes. Please break this into pull requests for refactoring, bug fixes and features.