[wdmaudiodev] Re: Audio: How should I make this?

  • From: "Juicehifi" <bernt@xxxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Tue, 16 Oct 2007 01:24:13 +0200

Thank you, Tim
 
Definition: "Solution" is used as a term for what I have in mind below.
 
I'll try to stick to the functional aspects for now since I do not know the
best way of making a solution, technically. Hopefully some of you  can
translate my need to a *very* high level solution alternative. 
 
"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?
 
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?
 
 
"Are you wanting to offer services for specific applications, or for all
applications?  DMOs are very low impact, but they require cooperation from
the application."
 
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.
 
Further - doesn't DMO require directsound/mme/wdm playback? These are not
favourites among the target group. Asio is first choise, kernel streaming a
good second.
 
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. Very few sound cards support it, it is a setup that
requires more than average PC-audio competence and it does not give the user
a flawless user experience.
 
Is this a "mission impossible"?
 
Best regards / vennlig hilsen

 

Bernt

 

-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Roberts
Sent: 16. oktober 2007 00:00
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Audio: How should I make this?


Juicehifi wrote: 


 
Questions from a fresh member. I want to make a solution that does the
following on XP and Vista:
 
1) Appears as a sound card driver in the control panel and in audio players.
2) Has a user interface where the user chooses the real sound card and API
to use (WDM, MME, Asio, DirectSound, Wasapi etc). The open source library
Port Audio will be used to stream waveformatextensible audio streams - with
or without the waveformatextensible header.


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.





3) Receives uncoded audio when selected as the driver.
4) Does some signal processing (DSP). A lot of RAM and a lot of CPU will be
used in certain cases. This is the main purpose of the solution.
5) Has a user interface where the user can start, stop, change the signal
processing. And other things.
6) Ports the audio to real sound card drivers  by using open source library
Port Audio.
7) Keeps the audio stream bit-perfect exept for the intended DSP. System
requirements should be taken care of by the choosen sound card and audio
API.
 
The solution doesn't have to be able to play from multiple sources
simultaneously.


Are you wanting to offer services for specific applications, or for all
applications?  DMOs are very low impact, but they require cooperation from
the application.

-- 

Tim Roberts, timr@xxxxxxxxx

Providenza & Boekelheide, Inc.

Other related posts: