[wdmaudiodev] Re: Remote desktop audio problem in different windows sessions.

  • From: "Jose Catena" <jc1@xxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Thu, 4 Jun 2009 00:36:22 +0200

 

Ø  How can i solve this problem, I want to route audio of only one session
to the one established connection.

The problem is that if your virtual driver is the default device, it
receives all audio sent to the default audio device already mixed, so I
don?t think it could separate what?s coming from different sessions. It may
switch on or off depending on the user or whatever, but on will be on for
everything at any given time (I mean everything that plays to that default
audio device).

So you may want to avoid using your virtual device as default, and direct
the output from application directly to your device when required. I think
this is not what you want if you want to route audio from any application,
as many won?t let you choose the audio device. If you wanted to route your
own app audio it?s obvious you had not end writing a driver.

If you need 

 

As some Microsoft guys have recommended here a couple of times, this kind of
things should be implemented in user mode much better. What they seem to
have a hard time to understand is that the windows audio subsystem, despite
of its complexity, does not provide the adequate hooks, so we have no
choice.

Of course we can develop an application, but when what we want is to process
(or  capture, route?) what?s coming from ANY application we are sold. At
least we want to capture basic directsound / mme, sophisticated stuff
employing directshow already provide ways. Where we need to hook is at the
sound api level still in user mode. We may write a directshow renderer, for
example, but most applications won?t use it because they don?t use
directshow and send output directly to directsound or wave/mme. I have been
studying the new stuff like GFX, APOs, etc. Unsuitable crap again.

If we had a way to hook in user mode before the stream is passed to kernel
components, it would be heaven: no kernel components that compromise system
stability for things that don?t need and shouldn?t be done in kernel mode;
no kernel/user transitions when routing the stream through user mode filters
like directshow or whatever, etc.

So here we are, writing complex virtual or filter drivers, forced into
kernel mode, for something that should be much better done in a very
different way, in user mode to begin with. Or doing some serious hacking at
sound API handlers to hook where we should but the system doesn?t want us to
hook. I?m actually trying to do it, but it?s being difficult and has many
disadvantages because as undocumented and unsupported, things may stop
working after system updates. It is not a solution, modification or
substitution of a system component is not a solution, what I intend is to
discover a way to do it cleanly, with very little success, things seem
really hard wired and a lot of stuff is glued together in the same module.

I hope someday we are heard, but couldn?t count on it, being the story as it
is. From Windows, expect new games, more application stuff, and of course
more and more weight, but don?t much basic infrastructure improvements.
Recently it has shown some efforts, but not enough, and always mixed with a
lot of crap. Without real competence and with massive unqualified feedback,
there?s no feel about things that aren?t being done well enough. Review the
posts in this forum dedicated to drivers along the years, and find how many
people arrived here with this very reasonable need of capturing audio coming
from third party applications, and the few times someone from MS answer is
to say that it should be done in directshow / user mode, without realizing
that there?s no way, and without ever thinking they might place a very
simple hook in the right place. They rather keep inventing more and more
things that we don?t need and won?t use like those crappy APOs.

 

I?m sorry sounding upset with MS. Very sorry. Actually all I want is to
point something that should be useful to improve things that are *necessary*
to improve as proven by the number of people arrives here asking how to do
it, but I could not avoid to sound upset because I have been working a lot
having to use techniques that shouldn?t be used for the task. Very
reasonable needs, no good solutions where it should be very easy to provide
by MS, along many years without seeing enough positive advances. So yes, I?m
upset with MS and I think I have all the right. But that is not the point.
The point is that I, as many others, have described a very legitimate need
that should be attended, so please forgive me for everything else. And sorry
again for my English, it?s more difficult to say it right when it?s not in
the native language.

 

 

 

From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Karthik Gurumurthy
Sent: Wednesday, 03 June, 2009 12:31
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Remote desktop audio problem in different windows
sessions.

 

Hi all,
           I have some peculiar problem here, 
1. I have developed an virtual audio device driver that is capable of
sending audio (played by any player) over a network by socket connection.
2. i open an remote connection from another Linux machine (rdesktop IP).
3. if i open the socket and receive the audio packets and then if i play it,
is playing perfectly.
4. Now in windows machine if i log in to different user and play an audio,
this audio  that is also being routed to the remote machine.

How can i solve this problem, I want to route audio of only one session to
the one established connection.

I got some pointers 
1. Can i use \\Session\\0\\DosDevice<device name> to restrict device to be
loaded only for session 0. then how can i createfile in the user mode (by
what name \\\\.\\name)
2. Or can i dynamically load the driver during each session?

Thanks and Regards
Karthik SG 

Other related posts: