[wdmaudiodev] Re: Naive beginner with only a concept: front filter to use a VST plugin.
- From: Don Gateley <dongateley@xxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Wed, 8 May 2013 14:34:37 -0700
Yeah, I well know that Microsoft has made it difficult. In fact that's
exactly why I'm trying to interest someone in making it easy. :-)
The thing that makes it stand outside the heuristics of that philosophy is
that it is not for high-performance applications, but just for giving users
a better listening experience. The path I use now has more latency than I
think would be incurred by this application. Currently I use Virtual Audio
Cable feeding the VSTHost Windows application which is hosting a modular
audio plugin, PlogueBiduleVST, do do the heavy lifting and it doesn't put
audio out of sync with video to a significant degree. What I'm proposing
would be similar but without the Virtual Audio Cable latency.
While highly desirable I don't know yet whether or how some of the controls
for an inner modular filter implementation could be mapped out to the user
and that could be a significant problem. The actual tweaking can be done
across a process boundry with the OSC protocol. I've tested that with
PlogueBiduleVST used as the inner modular host and a smart phone OSC
controller but presenting a control surface within Windows that uses OSC
could be hairy and I don't really want to limit the choice of an inner
processing plugin to PlogueBidule due to its proprietary nature.
On Wed, May 8, 2013 at 10:57 AM, Tim Roberts <timr@xxxxxxxxx> wrote:
> Don Gateley wrote:
> >
> > 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?
>
> I don't think you misdirected your query at all. The people who would
> know how to do this live on this list.
>
> One issue is that you're up against a philosophy problem. The
> overarching mantra in the redesign of the Audio Engine in Vista was
> efficiency and low latency. On a system with an HDAudio device (which
> is most systems these days), audio traffic never passes through kernel
> mode at all. The Audio Engine process writes directly to the board's
> audio buffers.
>
> Microsoft has made it difficult to insert arbitrary helpful "filters" in
> the audio path, because that makes the path non-deterministic for
> high-performance audio applications. What you are doing here is counter
> to that trend. Instead of app to audio engine to device, you'll now
> have app to kernel interceptor to user-mode VST host to VST graph to
> audio engine to device. That's a lot of players.
>
> I'm not saying this is impossible, just that this is a somewhat bigger
> problem than you may realize. I see your concept, and I think it could
> be made to work, but it's a big job.
>
> --
> Tim Roberts, timr@xxxxxxxxx
> Providenza & Boekelheide, Inc.
>
> ******************
>
> 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/
>
>
Other related posts:
