@andgalf,
As I say, the version I posted is a function, which can be used in many situations rather than a one-off event. 
As a function it also serves in a much broader sense, and accommodates some issues in a broader usage of it.
The key fixing point is that a placeable can be used to play the sound, BUT may not be what you want. This is the “key” to the issue you were trying to resolve, but only assuming the PC was already carrying out an action. (See next.) However, in time, you may find you want to have this facility in many other situations - or maybe not?
The History of the Function
Now, here is a brief summary of why the function ended up as it did. Basically, the ideal solution is to have the PC play the sound directly, as it plays instantly. However, as others have also discovered, if the PC is already doing something else, we do not want to interrupt their actions to play the sound and so having a nearby placeable do it instead is a good substitute.
A downside of using a placeable is that if it is not close enough (less than 20 metres), then you still do not hear the sound it plays. Therefore, the solution was to create a temporary placeable to play the sound. This, however, requires the 0.2 second delay to play the sound.
Like @travus, I originally also deleted this temporary object in one of my earliest renditions of the function. However, I found that I also needed to have two sounds (or more) play close together. Or, I often needed to play new sounds a short while later. Therefore, deleting the placeable shortly after creation appeared pointless, especially as it took next to no resources and could always be reliably called upon again without the need of the 0.2 delay that it requires on first creation. (My own object was scaled 0.001, not useable, made walkable and plot to eliminate any “intrusion”.)
The ideal solution for my own requirement was to have the ability to:-
a) Have the sound file play as close to immediate as possible, whenever possible.
b) Have a sound file play that did not interrupt the PC actions.
So, this (what seems like a rather convoluted script), actually recognises and overcomes these issues as best as possible, by (a) first trying to rely on placeables I know to exist, (b) the PC themselves if not already doing something and ( c) only relying on a new placeable creation (with 0.2 sec delay) as and when really necessary. If the latter, then no longer destroy this “temp” object, as I can use it reliably again moving forward. Check out the debug feedback to see it in operation.
There is one other last “check” I have in the function, to do with a placeable potentially already playing a sound. This check insures the sound currently being played is not interrupted by another call to it to play another sound before the latter is finished playing. This is unlikely to be required by you, but I left it in to show that it can be required in certain circumstances.
The bottom line, again, like previous points we have discussed, I provide you with the “fullest” fix I have to date, which not only covers your immediate issue, but may well cover points you have not yet considered moving forward. This is how I have always been helped in the forums, and I think helps us all to learn more.
That all said, the simplest script for a one-off situation where the slight delay does not matter, then the basic script is all you need. However, I would also add that if the PC is not doing anything when the sound is needed to be played, then the even easier option would be to use:-
AssignCommand(oPC, ClearAllActions());
AssignCommand(oPC, ActionDoCommand(PlaySound(sSound, TRUE)));
Where sSound is your sound file reference.
NOTE, however, that while this is probably the cleanest section of the code to do the task most simply, and immediately, it does require the PC not to be doing anything when the code is called, which is why my checks are in there. (It does not even need any placeable creation!)
It’s a case of take what you need to do the job you require, but note the limitations of what you leave out or how you thereafter go ahead.
I hoped that helped explain some of the potential pitfalls or more efficient usage for you.
