Adds capability for blocking calls to SoundClient's play.

[felixduvallet]

The SoundClient can now be asked to wait until the requested sound has finished playing before returning, by making use of @aginika 's actionlib implementation. This removes the need for manual sleeping after a sound request is published. The default (out-of-the-box) behavior is unchanged (SoundClient returns immediately) so this should be transparent to everyone.

I also added an example (soundclient_example.py) that shows how to use the SoundClient in both blocking and non-blocking modes.

Lastly I snuck in some linting (trailing whitespace, new-style python classes), let me know if you object.

[trainman419]

Beautiful, clean and well implemented!

I have one thought about the overall API. As implemented, the user/developer has to choose between all requests being non-blocking, or all requests being blocking when they create their SoundClient.

What do you think about having blocking as an argument to play() and playWave() instead?

[felixduvallet]

I think that would also be a very reasonable way to do it, I went for the class-wide setting because it would be:

1. fewer LOC to change & review: each method of libsoundplay would have to change.
2. fewer things to remember for the user (changing each call to play()/say()/etc.. vs adding one flag in the constructor): personally this is more important to my use case

One compromise would be to provide the option in both places (SoundClient(blocking=true) and play(blocking=true)/etc, but I am afraid this could get confusing (presumably the play() call would take precedence, but only if the argument is specified explicitly??). The logic would definitely get a little weird.

There would still exist a workaround in this implementation: the user could have two SoundClient() instances: one blocking and one not.

Perhaps someone else can weigh in on this with their use case.

In any case I'd be happy to update this pull request if you feel the blocking argument should belong in the class to play/playWave/say/etc...

[trainman419]

Adding a per-method flag for blocking or non-blocking is definitely more work, but I also think it's clearer.

There are also a number of methods for which a blocking call to sound_play does not make sense; for example when repeating a sound, or when stopping a sound that is already playing. I think this is the most compelling reason to have a blocking flag on each method.

[felixduvallet]

@trainman419 I agree that calling play/repeat with an explicit blocking argument is a good use-case.

I updated the SoundClient to take in an explicit (but optional) blocking=True|False argument for each play call (say/play*/repeat*). This over-rides the class-wide blocking setting (NOTE: I still think it's good to have the option to choose the standard behavior).

I also updated the example to show this behavior in action.

I did not implement the blocking behavior this for stop() since I didn't think it made sense there, but since personally I don't really use the start/stop behavior I may be mistaken. Please advise.

[felixduvallet]

@trainman419 friendly ping on this PR.

[trainman419]

Sorry; things have been very busy lately.

I agree that a blocking stop() doesn't make much sense.

This looks great! Thanks for the update and the blocking flag on individual methods, and thanks for updating the docstrings!

[trainman419]

I've cherry-picked these changes onto the Indigo branch as well.