This is simply because the large number of game objects causes a long Animators.Update (see Profiler) that ranges from 12-28 ms on a fast computer. Thus frames will be skipped, and there will therefore be less frequent frame updates than the code aims for with it's 20 ms throttling. Both Play and PlayOneShot are equally affected by this, and to make things worse the chosen "Best Performance" setting in the Audio Settings results in the largest DSP buffer used (4x as large as "Best latency"), so that further increases the likeliness of having large gaps between the frame update and the point at which the audio playback event is handled. If you want rock-solid timing of sub-frametime, you need to use PlayScheduled to trigger multiple events to occur during the next frame update, and as an AudioSource can only handle one scheduled playback event at a time, you need to delegate these out to multiple sources (from a pool so they can be reused efficiently).