Hello! I'm working on enabling inter-process communication (IPC) between a Windows Audio Processing Object (APO) and a C# user program. I've read that it's possible to register the APO’s COM server in the Running Object Table (ROT) at startup. Can the C# program then access the ROT to obtain a reference to the running COM object for communication purposes?
Thanks!
COM is a specification for a binary interface that components can use to communicate with each other. There are both in-process servers (DLLs that are loaded into the caller's address space) and out of process servers (EXEs that run in their own address space). I'm not sure if it is possible for an in process server to also act as an out of process server, but I wouldn't think so. Even if it works, I wouldn't think it wise.
While there is extensive support for COM in .NET (including C#) it is not considered one of the best ways in modern development.
Depending on what you need to communicate, there are multiple ways. Before suggesting something, it might help to understand the larger goal
Thanks for your response! The main goal here is to send audio data from a user program to an APO in real time so that it can be mixed with microphone input. Alongside this, I'd like to be able to adjust various settings and parameters within the APO. It would also be great to have the ability to access information from the APO, such as audio formats and other details.
I did some research on how to accomplish this, but there are multiple mechanisms available for IPC, and I don’t know which one will fit my requirements best.
That sounds like two different requirements. Sending a stream of audio data and some request / response interfaces
do you anticipate that the UM program will always be running locally, or could it be running on a remote system?
is the audio data a byte stream or is it packetized (each byte can be used by itself, or I need to process bytes together in chunks of fixed or variable size)
I figured that the mechanisms used to send the audio data and to handle other requests might be different due to their nature, but if possible, I'd prefer not to have different implementations to avoid complexity. I've seen people using gRPC for communication with APOs, but it seems kind of overkill. There must be a cleaner solution.
What about RPC seems overkill?
The thing Mr Bond is missing is that an APO is already a fully registered COM object. They're not inventing something new here, they're exploiting a path that already exists.
The difficulty is that an APO DLL, when active, is already loaded in a separate process -- the Audio Engine process. Technically speaking, it is certainly possible for your APO to register itself in the ROT, and have your other process communicate via that handle. However, an APO runs in real-time. You can't afford to have delays or interference in the data flow. The Audio Engine monitors the performance and will shut you down if that happens.
It's also true that an APO is intended to be part of the hardware -- you are not supposed to install APOs except in the INF for a specific piece of hardware. It is possible to hack your APO into place for other devices, but Microsoft doesn't like it and doesn't support it. What you're talking about is USUALLY implemented via a virtual audio driver, not via an APO.
I freely admin to knowing a lot more about COM than the audio system, but assuming that this DLL is already an in-process server with the audio engine, is it possible or advisable for that instance to also function as an out of process server?
Yes, that's mostly what the ROT is for. People have used it for years with DirectShow to control filters in another process.
Whatever I don't know (which is probably a lot) notwithstanding, if this were my project I would not want to use COM for anything where it wasn't absolutely required. Certainly for a side band interface, there are lots of choices.
Could it be a good approach to establish a gRPC connection between the APO and the C# user app using named pipes? I came across this article and learned that gRPC could be used through named pipes instead of TCP/IP.
That article seems to be about making a C# RPC server & client. It looks like it is using the RPC over HTTP protocol, which is a lot. While the code to do this in C# looks short, there is a lot going on here. Presumably, your APO COM server is a C++ DLL, so that's not going to be easy to implement.
If you want something simple, and are thinking about named pipes, then a pipe server using message oriented pipes could work. Look at CreateNamedPipe. There are lots of examples on the net
there are many other options