adding wdmaudiodev back
On Thu, Sep 29, 2016 at 11:46 PM, ambrish dantrey <a4ambrish@xxxxxxxxx>
wrote:
What about ISV players that play high bitrate contents from BDs. I have
seen them use DRM before. A few years ago, I wrote a test application that
could render any plain LPCM data as protected content. It seemed to work as
expected. Has anything changed in this aspect in Win10?
Please note I am not suggesting this as a solution, just curious since you
mentioned that marking content to be protected wouldn't do anything for me.
On Thu, Sep 29, 2016 at 11:10 PM, Matthew van Eerde <
Matthew.van.Eerde@xxxxxxxxxxxxx> wrote:
+wdmaudiodev again
I’m glad you asked, because marking the voice chat data as protected will
not do anything helpful for you. It’s really for paid music services that
want to protect their content from being extracted digitally, e.g. anything
that uses PlayReady.
The solution to your problem, I think, is to break the feedback loop
using other means, such as acoustic echo cancelation.
*From: *ambrish dantrey <a4ambrish@xxxxxxxxx>
*Sent: *Thursday, September 29, 2016 10:33 AM
*To: *Matthew van Eerde <Matthew.van.Eerde@xxxxxxxxxxxxx>
*Subject: *Re: [wdmaudiodev] Re: AUDCLNT_STREAMFLAGS_LOOPBACK
Thanks. I have tried this approach and it works under limited testing but
as you mentioned, it seems rather elaborate way of achieving this.
What happens if I mark the voice chat data as protected? I know it would
prevent loopback mode from capturing it but would other applications still
be able to render on that endpoint?
On Thu, Sep 29, 2016 at 10:58 PM, Matthew van Eerde <
Matthew.van.Eerde@xxxxxxxxxxxxx> wrote:
You can get what is coming out of the speaker, but you cannot get
everything-coming-out-the-speaker-except-for-one-app.
I have heard of people ginning up a solution based on virtual audio
endpoints.
1. Suppose your physical output is Speakers.
2. Create a new virtual endpoint – call it Virtual – and make it
the default audio output.
3. All audio apps will play to Virtual.
4. Except your app. Your app will play directly to Speakers.
5. Create a virtual audio cable from Virtual to Speakers.
6. So everything ends up coming out of Speakers.
7. Have your app do loopback capture on Virtual
This is, of course, a tremendous hack.
*From: *ambrish dantrey <a4ambrish@xxxxxxxxx>
*Sent: *Thursday, September 29, 2016 10:12 AM
*To: *wdmaudiodev@xxxxxxxxxxxxx
*Subject: *[wdmaudiodev] Re: AUDCLNT_STREAMFLAGS_LOOPBACK
To elaborate further, my application is a chat application. It intends
to render is audio coming from client. There is another application that
uses loopback mode to capture audio data and send it back to client.
Right now, client's voice, that gets played out on default endpoint,
gets recorded using loopback mode and gets sent back to client, creating a
bad echo effect.
On Thu, Sep 29, 2016 at 10:28 PM, ambrish dantrey <a4ambrish@xxxxxxxxx>
wrote:
Hi Guys,
I know I can initialize an IAudioClient with AUDCLNT_STREAMFLAGS_LOOPBACK
flag and it would let me capture audio data from Windows audio mixer. I
also know that this doesn't work if an application has opened its audio
stream in exclusive mode.
Is there another way for application to indicate that it doesn't want
its data to be captured using loopback mode, but without using endpoint in
exclusive mode? I want to write a render application that plays audio data
in shared mode (rendering on default audio endpoint along with other
applications) but I don't want my data to be captured by an application
which is using loopback capture.
Please note that intention behind this question is not security or
content protection. There is a peculiar usecase I am trying to enable.
Would appreciate any insights greatly.
Thanks
