PlaySound() has quite significant delay in Vista!!!

PlaySound() has quite significant delay in Vista!!!

Post by Jack » Wed, 16 May 2007 06:02:18

In Vista Ultimate there is a delay starting playing a sound when using

PlaySound lname, App.hInstance, SND_FILENAME + SND_ASYNC
PlaySound lname, App.hInstance, SND_FILENAME + SND_SYNC

Is that only on my computer or it is a known fact?
I have a dual boot system, and in Windows XP there is not delay.


PlaySound() has quite significant delay in Vista!!!

Post by Mike Willi » Wed, 16 May 2007 15:27:16

I've come across that problem accasionally both on Vista machines and on XP
machines, and also the same problem with MCISendString and other similar
methods. Oddly enough my Vista machine seems to be playing sndPlaySound okay
at the moment, but I seem to recall it having the time delay problem with
some MCISendString code the other week (or was it the MM Control)? Curiouser
and curioser. Mind you, I've got XP and Vista in cradles on my main machine,
and XP on my laptop, so I'm not exactly sure what system I was using when
the problem occurred, except for the fact that I know for certain it can
also happen on XP because it also happend to me even when Vista was just a
gleam in Billy's eye. I'm wondering if it might be something to do with that
rather *** DRM stuff? Anyway, the quartz type library seems to work very
well on all systems, with no problems whatsoever, and is very flexible too.
Does the following work okay for you? You'll need to use Project /
References to set a reference to quartz.dll (aka ActiveMove type library).
It is present on virtually all systems from Win98 upwards so you won't need
to distribute anything extra with your app. Anyway, there are all sorts of
ways to use this type library to play all sorts of sounds, including wav,
midi, mp3 and others and also to play movies. Here is a "bare minimum"
example. Let me know if it works okay on your system:

Private Sub Command1_Click()
Static player1 As Object
Set player1 = New FilgraphManager
player1.RenderFile "c:\ringout.wav" ' obviously change this line
End Sub



PlaySound() has quite significant delay in Vista!!!

Post by Mike Willi » Wed, 16 May 2007 15:45:39

By the way, you might like to also try the code I just posted on other kinds
of file as well as wavs, such as midi or mp3 or mpg. The exact same code
will work for all of them. I've got Kate Bush dancing around on my screen at
the moment ;-)


PlaySound() has quite significant delay in Vista!!!

Post by Chris P » Wed, 16 May 2007 23:35:10

MCI uses the same DirectShow/ActiveMovie API under the hood so there
shouldn't be much difference. It will be interesting to see your results.

[MS MVP for DirectShow / MediaFoundation]

PlaySound() has quite significant delay in Vista!!!

Post by Mike Willi » Thu, 17 May 2007 05:25:10

Would anyone here like to help me out?

I posted a further message some time ago, in response to Chris P's message
in this thread, but because of the way this newsgroup stuff works it seems
to have been posted only to the programmer.mmedia group (where Chris P
normally lives), so here it is again (below). I would appreciate it if
anyone here would kindly try the test code for me and let me know the
result, and the system they are using. Paste the example into a VB Form
containing one Microsoft Multimedia Control and two Command Buttons and use
Project / References to set a reference to the ActiveMovie type library
(quartz.dll is system32). Change the hard coded path to a midi file that
exists on your own system. Also, if anyone here knows more about the
Multimedia Control than I do (which won't be difficult as I know very
little!) and if you can tell me if I am doing anything wrong then I would
very much appreciate it.


[Copy of previous post] Further to my previous post, I've just tried out the
Multimedia Control on my Vista machine and it seems to be behaving itself at
the moment when playing wav files, but it is giving me serious "delay"
problems when playing midi files. On a short test midi file it is giving a
delay of *seven seconds* before the song starts playing, whereas the exact
same midi file plays straight away (certainly less than half a second delay)
using the ActiveMovie quartz type library. I don't get very involved in
Multimedia stuff myself, so perhaps you can see whether I am doing anything
wrong in the following code? Seven seconds is a *very* long delay to begin
playing a midi file (especially when quartz dll plays it immediately) and I
cannot help wondering whether this is in some way deliberate ;-) Anyway,
you might like to try the following code on your own machine (with a
reference to quartz.dll) using a suitable small midi file:

[addendum] I've just swapped drives on this machine and tried exactly the
same code on the same hardware but running WinXP and I get a similar result,
with the FilgraphManager code playing the midi file immediately and the
Multimedia Control taking 7 seconds to begin playing. Changing to a
different midi file (one that is normally present on default Windows
installations) makes the Multimedia Control code a little better, but it
still takes about 3 seconds to begin pl;aying, whereas again the
FilgraphManager code begins playing immediately.


Private Sub Command1_Click()
MMControl1.Notify = False
MMControl1.Wait = False
MMControl1.Shareable = False
MMControl1.DeviceType = "Sequencer"
MMControl1.FileName = "c:\nutcracker.mid"
MMControl1.Command = "Open"
MMControl1.Command = "Play"
End Sub

Private Sub Command2_Click()
Static player1 As Object
Set player1 = New FilgraphManager
player1.RenderFile "c:\nutcracker.mid"
End Sub

PlaySound() has quite significant delay in Vista!!!

Post by Jack » Fri, 18 May 2007 10:54:42

tried your code.
In WinXP both MM and FilgraphManager play midi the same, maybe
FilgraphManager has slight delay ~ 1sec
In Vista I cannot use MM (I do not have Microsoft Multimedia Control
available) but FilgraphManager starts with 1 second delay for sure.

"Mike Williams" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


PlaySound() has quite significant delay in Vista!!!

Post by hmsik » Sat, 26 May 2007 23:36:46

Tuesday, May 15, 2007 10:45 AM LarryOsterman
Blocking your UI thread with PlaySound

For better or worse, the Windows UI model ties a window to a
particular thread, that has led to a programming paradigm where work
is divided between "UI threads" and "I/O threads". In order to keep
your application responsive, it's critically important to not perform
any blocking operations on your UI thread and instead do them on the
"I/O threads".

One thing that people don't always realize is that even asynchronous
APIs block. This isn't surprising - a single processor core can only
do one thing at a time (to be pedantic, the processor cores can and do
more than one thing at a time, but the C (or C++) language is defined
to run on an abstract machine that enforces various strict ordering
semantics, thus the C (or C++) compiler will do what is necessary to
ensure that the languages ordering semantics are met[1]).

So what does an "async" API really do given that most APIs are written
in languages that don't contain native concurrency support[2] ? Well,
usually it packages up the parameters to the API and queues it to a
worker thread (this is what the CLR does for many of the "async" CLR
operations - they're not really asynchronous, they're just synchronous
calls made on some other thread).

For some asynchronous APIs (like ReadFile and WriteFile) you CAN
implement real asynchronous semantics - under the covers, the ReadFile
API adds a read request to a worker queue and starts the I/O
associated with reading the data from disk, when the hardware
interrupt occurs indicating that the read is complete, the I/O
subsystem removes the read request from the worker queue and completes
it [3].

The critical thing to realize is that even for the APIs that do
support real asynchronous activity there's STILL synchronous
processing going on - you still need to package up the parameters for
the operation and add them to a queue somewhere, and that can stall
the processor. For most operations it doesn't matter - the time to
queue the parameters is sufficiently small that you can perform it on
the UI thread.

Hi !

Found this @ MSDN :

And sometimes it isn't. It turns out that my favorite API, PlaySound
is a great example of this. PlaySound provides asynchronous behavior
with the SND_ASYNC flag, but it does a fair amount of work before
dispatching the call to a worker thread. Unfortunately, some of the
processing done in the application thread can take many milliseconds
(especially if this is the first call to winmm.dll).

I originally wrote down the operations that were performed on the
application's thread, but then I realized that doing so would cement
the behavior for all time, and I don't want to do that. So the
following will have to suffice:

In general, PlaySound does the processing necessary to determine the
filename (or WAV image) in the application thread and posts the real
work (rendering the sound) to a worker thread. That processing is
likely to involve synchronous I/Os and registry reads. It may involve
searching the path looking for a filename. For SND_RESOURCE, it will
also involve reading the resource data from the specified module.

Because of this processing, it's possible for the PlaySound(...,
SND_ASYNC) operation to take several hundred milliseconds (and we've
seen it take as long as several seconds if the current directory is
located on an unreliable network). As a