[wdmaudiodev] Re: Audio: How should I make this?
- From: "Juicehifi" <bernt@xxxxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Tue, 16 Oct 2007 02:44:45 +0200
Thank you Tim,
Some of todays users send the audio to an available audio output - then
loops the audio back to audio inputs - then from the inputs to a VST/DX host
for processing and finally to the outputs of the the sound card that's
actually being used for the playback. This solution strikes me as
unneccesary complicated.
"Isn't that exactly the solution you are proposing, with the one exception
that you'll configure the playback path yourself?"
Not exactly. I do not really see the need to go player ->sound card output
-> sound card input -> dsp -> another soundcard output.
Player -> dsp -> soundcard output ought to do it.
I will certainly look further into the filter driver and APO alternatives.
Best regards / vennlig hilsen
Bernt
-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Roberts
Sent: 16. oktober 2007 02:23
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Audio: How should I make this?
Juicehifi wrote:
"Why would you choose to do it that way, instead of writing a filter driver
(for XP) or an APO (for Vista)? Those would seem to be much less intrusive
mechanisms, with much less reinventing of the wheel."
I was hoping that this would be as simple as splitting one of the DDK audio
driver examples, take the user mode interface from it, send the audio to
buffers for processing and build a player on the back side for the
downstream - and syncronize the two audiostreams by forwarding the callbacks
upstream. Is this a very complicated task?
I, personally, would judge it to be much more complicated than the filter
driver and APO solutions. The big advantage of a filter driver is that all
of the boilerplate stuff is being done for you by the driver you're leeching
from. You intercept and modify only those requests that interest you.
The solution doesn't really have to be a driver, but it is important that
the solution is connected to the choosen sound card in such a way that all
audio sent to this particular sound card goes through the solution. Each
time the machine is turned on and until the user chooses to disable the
solution.
Maybe it should be a filter driver and an APO. I don't know. Will a filter
driver / APO solution work with Asio playback in addition to the windows
audio API?
The filter driver certainly should. ASIO on XP talks to the kernel
streaming driver, so it should pick up any filter. On Vista, I don't know.
The ASIO web site says it now supports WaveRT drivers on Vista, but I don't
know whether that means it talks DIRECTLY to the WaveRT drivers. If so,
that would bypass any APOs.
Note, however, that I have zero personal experience with ASIO. It is
possible that I have waded out of my depth here and should just shut up.
The solution should not be dependant on cooperation from the application. In
fact, removing dependancies of the various audio sources is one of the main
motivations for making a solution. It is also important that the solution is
guaranteed to be in the audio rendering stream whenever audio is routed to
the subject sound card. The solution should have a very straightforward
installation procedure that is works as long as the player and sound card
supports certain defined audio API's. And as long as decoded autio is
played. This also means that it will have to sit further down the stream
than a mp3 / AC3 or any other audio decoder would sit.
Yes, naturally. This also means that your driver will not be allowed to
participate in protected content on Vista.
Is this a "mission impossible"?
It's not "mission impossible", but it's not a slam dunk, either.
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
Other related posts:
