I think it is possible to come up with a system that comes close to what you are proposing. It consists of two components: a WDM component and a user mode application.
The WDM component presents a virtual audio output to the system. It has a hidden (proprietary) interface that allows the user mode application to connect to the audio stream. If the user mode application is not connected, the WDM component just drops any incoming audio packets. This is much like VAC works, except there is no virtual input (at least it is not publicly accesible).
The user mode application receives audio from the WDM component. It can process the audio using VST plugins and outputs the results through ASIO or another user mode audio API (ASIO probably preferable because of low attainable latency). The user mode application can be made to start automatically when the system starts, possibly running as tray icon application. Configuration is done through the user mode application.
It may be possible to connect the configuration part with the WDM component's property page. I am not an expert in that area, but it seems likely there are ways to do that.
Evert van der Poll On 5/8/2013 4:34 AM, Don Gateley wrote:
Thanks, Tim. I understand the need for an integrated, but simple, VST host that uses the Steinberg API for this. My reason for wanting a driver/device interface is not to do any low level kernel processing but simply to give a user a familiar way to direct output to a DSP filter via the "Windows Sound" control panel and to configure the plugin and real output device via it. Is there a path to such a driver interface that doesn't involve kernel mode (other than perhaps as a hidden bridge)? I clearly misdirected my query. Can you suggest a forum or list more appropriate?Even though I am a programmer I am not capable of programming this myself. I was in real time embedded control, not Windows development. I work at a different level these days, audio DSP applications, and I want to explore pulling together the necessary expertise to do something that I and probably others would find useful both for development and deployment of audio processing functions on Windows which is much less a kludge than what is now required.Thanks again.On Tue, May 7, 2013 at 3:11 PM, Tim Roberts <timr@xxxxxxxxx <mailto:timr@xxxxxxxxx>> wrote:Don Gateley wrote: > > I would like a WDM front filter that is configurable to the extent of: > > 1) naming the path to my VST plugins directory, > 2) naming a single VST plugin to insert as a filter, > 3) naming a real audio device to receive the output and > 4) specifying parameters to the VST plugin and opening it's GUI. > > In my first usage it would name and utilize the PlogueBiduleVST plugin > which is an entire framework for building up more complex flows and > processes. VST plugins are user-mode modules. They're just DLLs. There's no kernel code involved, so WDM doesn't apply. At the bottom end, the hosting application pumps the resulting audio feed into the Audio Engine for rendering to a speaker, but there must BE a hosting application. They can't run on their own. > I am successfully doing this now via the Virtual Audio Cable and > VSTHost applications but would like to considerably simplify the > mechanism for use by others with a wish to filter Windows audio in a > general and flexible way. There's really no easier way to do this. You are trying to connect two incompatible audio worlds here, so you're always going to need an ugly adapter plate. That's what VAC is doing for you. Even if you made your own VAC clone, you can't load user-mode DLLs in the kernel, and you can't do UI stuff from the kernel. You'd still have to have the VAC clone pipe the data to a VST host of some kind. -- Tim Roberts, timr@xxxxxxxxx <mailto:timr@xxxxxxxxx> Providenza & Boekelheide, Inc. ****************** WDMAUDIODEV addresses: Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx <mailto:wdmaudiodev@xxxxxxxxxxxxx> Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx <mailto:wdmaudiodev-request@xxxxxxxxxxxxx>?subject=subscribe Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx <mailto:wdmaudiodev-request@xxxxxxxxxxxxx>?subject=unsubscribe Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx <mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx> URL to WDMAUDIODEV page: http://www.wdmaudiodev.com/
