One major problem with this is sv_play and sv_end_of_song. You can't use sv_end_of_song in the context of waiting for the slot to start/stop playing, since it risks being nondeterministic. While I would agree that marking some of the methods as having their effects delayed, this is quite a problem.
Current workarounds include checking the current line to see if it moved, but it's quite silly.
I would propose setting a flag internally to true, which would mean that this slot will eventually start playing, and set it to false if it is playing and any event stopped the playback. This way the client code would make more sense, and no big changes would be involved on the engine side of things
![Smile :)](./images/smilies/smile.gif)
There is also no way of seeing if events were processed, so client code can't know how long to wait for events sent with timestamp t=0 to be processed. An integer-returning function returning the count of sound buffers processed so far should be enough.