|
|
|
date: Thu, 12 Jun 2008 03:30:00 -0700,
group: microsoft.public.win32.programmer.directx.audio
back
Re: stop sounds of a different process
Hi,
Thanks for the quick response. it took me a while but i managed to make the
hooking work (i'm using some HookImportFunction which was written by
codeproject http://www.codeproject.com/KB/DLL/hookimport.aspx ). however, i'm
trying to hook some of the winmm.dll functions, and while i can hook the
waveOutOpen, i'm unable to hook the PlaySound.
When i look at the "dll API" using "dependecy walker" (going from the exe
which i try to hook, not directly from the dll winmm.dll) i see that i can
only get access to functions of winmm.dll with a "green C" box next to them
and which do not have a bounded entry point. while all the rest (including
among them PlaySound) are not accesiable.
anyway idea what's the difference between the 2 function groups?
"Alessandro Angeli" wrote:
> From: "Oded"
>
> > I have a program (written in C++) which pauses other
> > processes (specific ones...) on certain scenarios, and
> > then resume their actions after a while. It does so by
> > basically pausing all the threads of the relevant process
> > (and then resuming them)
> > My problem is, sometimes these processes are in the
> > middle of playing music/sound. what will happen in this
> > scenario is that a small portion of the sound they are
> > playing will be stuck in a loop, creating a very annoying
> > sound (until the process threads are resumed).
> > The question is - is there a way to "wipe clean" all
> > sound streams which were sent to the sound device (from
> > any process running on the machine)? bare in mind that
> > i'm not looking for "lowering the volume" of the machine,
> > since my applicaiton will need to use sound as well. 10x.
>
> There is no easy way.
>
> While process and thread handles are kernel objects that can
> be enumerared and used by remote processes through a single
> simple API, sound I/O handles are user-mode objects that can
> only be seen by the owning process and there are also
> several sound APIs.
>
> You have 2 choices, both long and dirty:
>
> 1. hook all known sound APIs (waveOut, DirectSound, Vista's
> WASAPI...) in all processes; this will work only with
> handles opened after the hook and it is very invasive
>
> 2. write a kernel-mode filter driver to sit on top of the
> different audio drivers (you may need different versions for
> different systems) that clears the sounds of suspended
> processes
>
>
>
> --
> // Alessandro Angeli
> // MVP :: DirectShow / MediaFoundation
> // mvpnews at riseoftheants dot com
> // http://www.riseoftheants.com/mmx/faq.htm
>
>
>
date: Sun, 15 Jun 2008 16:10:00 -0700
author: Oded
Re: stop sounds of a different process
From: "Oded"
> Thanks for the quick response. it took me a while but i
> managed to make the hooking work (i'm using some
> HookImportFunction which was written by codeproject
> http://www.codeproject.com/KB/DLL/hookimport.aspx ).
> however, i'm trying to hook some of the winmm.dll
> functions, and while i can hook the waveOutOpen, i'm
> unable to hook the PlaySound.
> When i look at the "dll API" using "dependecy walker"
> (going from the exe which i try to hook, not directly
> from the dll winmm.dll) i see that i can only get access
> to functions of winmm.dll with a "green C" box next to
> them and which do not have a bounded entry point. while
> all the rest (including among them PlaySound) are not
> accesiable.
> anyway idea what's the difference between the 2 function
> groups?
The code you are using patches the DLL's IAT, which is
tricky and, not knowing the details on how and when you hook
what and where, it is hard to say. A safer hooking technique
works by patching the function itself (see my FAQ). In any
case, PlaySound() itself should only be an high-level
function that uses waveOut or DirectSound underneath, which
means that hooking those will automatically take care of
PlaySound and other high-level functions as well.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
date: Sun, 15 Jun 2008 19:37:51 -0400
author: Alessandro Angeli
Re: stop sounds of a different process
i'm now using the detour library which seems to do the job.
thanks for the tip.
"Alessandro Angeli" wrote:
> From: "Oded"
>
> > Thanks for the quick response. it took me a while but i
> > managed to make the hooking work (i'm using some
> > HookImportFunction which was written by codeproject
> > http://www.codeproject.com/KB/DLL/hookimport.aspx ).
> > however, i'm trying to hook some of the winmm.dll
> > functions, and while i can hook the waveOutOpen, i'm
> > unable to hook the PlaySound.
> > When i look at the "dll API" using "dependecy walker"
> > (going from the exe which i try to hook, not directly
> > from the dll winmm.dll) i see that i can only get access
> > to functions of winmm.dll with a "green C" box next to
> > them and which do not have a bounded entry point. while
> > all the rest (including among them PlaySound) are not
> > accesiable.
> > anyway idea what's the difference between the 2 function
> > groups?
>
> The code you are using patches the DLL's IAT, which is
> tricky and, not knowing the details on how and when you hook
> what and where, it is hard to say. A safer hooking technique
> works by patching the function itself (see my FAQ). In any
> case, PlaySound() itself should only be an high-level
> function that uses waveOut or DirectSound underneath, which
> means that hooking those will automatically take care of
> PlaySound and other high-level functions as well.
>
> --
> // Alessandro Angeli
> // MVP :: DirectShow / MediaFoundation
> // mvpnews at riseoftheants dot com
> // http://www.riseoftheants.com/mmx/faq.htm
>
>
>
date: Thu, 19 Jun 2008 05:54:02 -0700
author: Oded
Re: stop sounds of a different process
Hi (sorry for the long thread)...
I have another small issue which i can't seem to resolve.
using detour library i managed to cause the application i'm hooking not to
use dsound.dll (direct sound) and force it to use waveout API (i hooked the
LoadLibrary and return NULL when i received the LoadLibrary("dsound.dll")
request).
Anyway i know the application is using the fmod library (for sounds API)
which supports both (waveOut and direct sound) so it works fine (this is just
a temporary hook for testing).
the problem is - although i get waveOutOpen/Write/Close calls in my hooks,
these are only called once the application is initialized. Afterward during
its run, and when sound for example is played when user press button /
animation starts, i do not see any waveOutWrite calls (which one would
expect) but i can hear the sound.
I also see that if in the original waveOutWrite calls which i received (in
my hook) i do not perform the actual write and just return MMSYSERR_NOERROR,
there is no sound in the game at all (which does make sense...).
i couldn't find any other API (checked also waveOutRestart) which might be
used instead.
Any ideas?
10x.
"Oded" wrote:
> i'm now using the detour library which seems to do the job.
> thanks for the tip.
>
> "Alessandro Angeli" wrote:
>
> > From: "Oded"
> >
> > > Thanks for the quick response. it took me a while but i
> > > managed to make the hooking work (i'm using some
> > > HookImportFunction which was written by codeproject
> > > http://www.codeproject.com/KB/DLL/hookimport.aspx ).
> > > however, i'm trying to hook some of the winmm.dll
> > > functions, and while i can hook the waveOutOpen, i'm
> > > unable to hook the PlaySound.
> > > When i look at the "dll API" using "dependecy walker"
> > > (going from the exe which i try to hook, not directly
> > > from the dll winmm.dll) i see that i can only get access
> > > to functions of winmm.dll with a "green C" box next to
> > > them and which do not have a bounded entry point. while
> > > all the rest (including among them PlaySound) are not
> > > accesiable.
> > > anyway idea what's the difference between the 2 function
> > > groups?
> >
> > The code you are using patches the DLL's IAT, which is
> > tricky and, not knowing the details on how and when you hook
> > what and where, it is hard to say. A safer hooking technique
> > works by patching the function itself (see my FAQ). In any
> > case, PlaySound() itself should only be an high-level
> > function that uses waveOut or DirectSound underneath, which
> > means that hooking those will automatically take care of
> > PlaySound and other high-level functions as well.
> >
> > --
> > // Alessandro Angeli
> > // MVP :: DirectShow / MediaFoundation
> > // mvpnews at riseoftheants dot com
> > // http://www.riseoftheants.com/mmx/faq.htm
> >
> >
> >
date: Sun, 22 Jun 2008 05:43:01 -0700
author: Oded
|
|
