If you compare the play lines to the end lines, you’ll notice that you have a 0 for play where you have a “value for the length of the audio file” for end—in both cases, it actually corresponds to the position in the audio file when the event is detected. So in your case, you always have an offset of 0, which means that the play event is triggered while the audio hasn’t started playing yet.
I’m afraid that the delays you are seeing mean that execution was slow for at least some of your participants. Unfortunately, you should see lines in your results file for any buffering that happened, but I just noticed that there is a typo in the code and those won’t end up in the results file… I’ll fix this in the next release.
If you see that the delays are systematically greater for some participants, I would say this is good indication that the conditions were not optimal for those, either because of a browser slowdown (for example due to many tabs open in parallel executing various scripts) or because the audio stream that’s normally cached got lost at some point and needed to buffer again.