Thanks for the response. Here is my scenario:
5.1 virtual audio driver --> ac3/spdif encoder --> virtual capture device
--> hdmi audio driver (3rd party) --> TV --> spdif to speaker
I was initially thinking of using the "playback through this device" option
in windows to connect the capture device and the hdmi driver. But this
option uses shared mode and hence the ac3 data is sent to the windows audio
engine for mixing. I do not know if there is a way to force it to use
exclusive mode. Now I am thinking of sending the ac3 data directly from the
virtual audio driver (after encoding) to the hdmi driver. I am assuming
this can be done using IoCallDriver in kernel mode. Am I in the right
On Thu, 24 Jan 2019 at 11:59, Matthew van Eerde <dmarc-noreply@xxxxxxxxxxxxx>
Can you elaborate a little more on your scenario? The usual way to play
Dolby Digital audio in shared mode is to decode it first, then mix it with
other audio, and then play the result of the mix.
If you want multichannel and your output transport is rate-limited to the
point where it can stream compressed 5.1 but not uncompressed 5.1 (e.g.
optical) then the usual technique is to use an encoding EFX that accepts
the uncompressed mix and compresses it in real time.
*From:* wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx>
on behalf of Gregory House <drghouse221b@xxxxxxxxx>
*Sent:* Wednesday, January 23, 2019 7:57:41 AM
*Subject:* [wdmaudiodev] Rendering audio on a different device in kernel
I am working on a capture device that sends ac3 data to a rendering
device. I was hoping this can be done using the "playback through this
device" option. But I found that this connects to the endpoint in shared
mode and sending ac3 requires exclusive mode. Is there anyway to gain
exclusive access to a rendering device from a kernel mode driver? I know
how to render audio in user mode using audioclient api. But is there
something similar for kernel mode? Any help would be appreciated!