<< ... the core audio APIs don't seem to provide any way of getting a
device interface for each capture endpoint that I can then use to send my
IOCTL commands. >>
You can't get a device interface handle, but you can activate IKsControl
directly on the controller device (the IMMDevice associated with the
KsFilter), which essentially gives you a device interface handle wrapped
in a C++ interface. It basically eliminates Franks step 3 and doesn't
require an additional node, so hopefully this will require minimal changes
to your existing code.
Here's the quickest way to get from endpoint to the device interface (sans
error handling)...
extern IMMDeviceEnumerator* g_pEnumerator;
HRESULT GetControllerDeviceFromEndpoint(IMMDevice* pEndpoint, IMMDevice**
ppController)
{
HRESULT hr;
CComPtr<IDeviceTopology> spTopology;
CComPtr<IConnector> spPlug;
LPWSTR pwstrControllerId = NULL;
*ppController = NULL;
hr = pEndpoint->Activate(__uuidof(IDeviceTopology), CLSCTX_ALL, NULL,
(void**)&spTopology);
// By definition, Endpoint devices only have 1 connector, representing
the plug.
hr = spTopology->GetConnector(0, &spPlug);
// This is the quickest way to get from an Endpoint plug to the audio
controller.
hr = spPlug->GetDeviceIdConnectedTo(&pwstrControllerId);
// Get IMMDevice ptr via device ID
hr = g_pEnumerator->GetDevice(pwstrControllerId, ppController);
// Remember to free device IDs using CoTaskMemFree
if (pwstrControllerId != NULL)
CoTaskMemFree(pwstrControllerId);
...
return hr;
}
HRESULT GetIKsControlFromEndpoint(IMMDevice* pEndpoint, IKsControl**
ppKsControl)
{
HRESULT hr;
CComPtr<IMMDevice> spController;
hr = GetControllerDeviceFromEndpoint(pEndpoint, &spController);
hr = spController->Activate(__uuidof(IKsControl), CLSCTX_INPROC_SERVER,
NULL, (void**)ppKsControl);
...
return hr;
}
Regards,
Mitch Rundle
This posting is provided "AS IS" with no warranties, and confers no
rights.
-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Jeff Pages
Sent: Sunday, January 07, 2007 3:40 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Matching device instances
Frank Yerrace wrote:
User-mode software can establish private communication to the kernel
audio
driver by:
1. Activate IDeviceTopology on the IMMDevice audio endpoint
2. Use the Device Topology API to walk to the connected "device" (where
"device" here
refers to the Device Topology sense of the word). This device represents
a
KS filter device
implemented by the audio driver.
3. Find the interesting "part" in this device's topology.
4. Activate and use IKsControl interface on that part. Calls to
IKsControl
on the "part" will
result in KS property, method, and event calls to the corresponding node
in the driver's topology.
The above is the same recommendation as in these posts:
//www.freelists.org/archives/wdmaudiodev/10-2006/msg00066.html
//www.freelists.org/archives/wdmaudiodev/10-2006/msg00067.html
Jeff, depending on the motivation behind your question this might address
your concern as well.
What we have is a couple of multiple-station radio capture cards - the AM
card digitizes the entire band and extracts any number of individual
stations in software, presenting each one as a virtual audio capture
device,
while the FM card uses multichannel digital-down-converter chips to
essentially do the same thing.
We need to provide specific control functions relating to the tuner side
of
this (getting and setting the station frequency, received signal strength
indicator, and stereo reception indicator in the case of the FM card).
Currently I'm using custom IOCTL calls to do this, and use waveInMessage
and
DRV_QUERYDEVICEINTERFACE to obtain a device interface for each waveIn
device.
This works fine, but for a new application we're doing that's intended
specifically to run on Vista, I'm looking at using the core audio APIs
rather than waveIn, as I'll be recording many audio channels and want to
minimise the overhead. However the core audio APIs don't seem to provide
any
way of getting a device interface for each capture endpoint that I can
then
use to send my IOCTL commands.
So now I'm wondering if I should really be putting some sort of custom
tuner
node in the topology tree and accessing that as you described using the
Device Topology API.
Any thoughts on this?
Jeff Pages
Innes Corporation Pty Ltd
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
