Forums Bug Reports /splay -q is slow to chain file

If I play a sound in loop in an audio editor, it's much faster than what /splay -q will produce, there seems to be a delay before the file is played again, would that be an issue with the api mIRC is using? Is there no way to get no delay?

Try with this file https://www.dropbox.com/s/7fckbxrdse2xcpr/pacman_chomp1.wav?dl=0

I used audacity (shift + play to loop the file): https://www.audacityteam.org/download/windows/
and in mIRC

Edit: the delay is not related to wav file, nor is related to the queue, using an event such as on wavend to play the file again has the same 'delay' as queuing.

If its a limitation of mIRC's scripting interpreter, I'd suggestion a new switch that denotes the file should be looped as soon as play ends:

Thanks for your bug report. If you are referring to the delay inbetween played sounds, there is little mIRC can do about this. The on WAVEEND event is triggered the moment the Windows API notifies mIRC that the sound has finished playing. So before playing the next sound, mIRC has to close a sound, trigger remote events, and play the next sound in the queue. All of this happens immediately in a sequence with no delays, so it is as fast as it can get.

I just tested using seek to reset the sound to the start in the actual code, the moment the API notifies that it has ended, and there is still a break inbetween both sounds. So my guess is that seamlessly playing a sound in a loop would require a very different implementation that is beyond the current /splay.

I am not looking for playing a file in a loop, that should be a seperate feature.

I am trying to 'chain' that sound in a nice way in my pacman game whenever pacman eats a pill, and it's not trivial.

One thing I noticed is that it takes at least 70ms to execute a simple /splay for this file, which may be the issue, could /splay cache the filename somehow?

That sounds about right, considering the amount of code involved to set up a splay. There is no provision for caching a sound. That would require a very different and more low-level implementation that loads sound data into memory for direct access by DirectShow, which is currently beyond the scope of /splay.

Alright, thanks for the information.