[wdmaudiodev] Re: Issues in installing custom sAPO.
- From: Frank Yerrace <Frank.Yerrace@xxxxxxxxxxxxx>
- To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Fri, 12 Oct 2012 17:53:53 +0000
Sorry, I'm not sure I entirely understand the relationship between some of the
comments, but I'll make some comments.
Yes, it's true some applications can use WASAPI exclusive mode to bypass APO
processing. Yes, applications can use ASIO if they want and if the installed
drivers support it. No, Windows does not have a documented, supported mechanism
for applications to communicate directly with APOs.
One example problematic scenario is when an app, let's say a VOIP app, wishes
to do some of its own signal processing that may or may not conflict with
processing that happens within the APOs or the hardware driver or the hardware
itself. There currently is no standard mechanism in Windows for the driver (and
its APOs) and the application to have awareness of each other's processing to
avoid conflicting or duplicate signal processing. Opening up a spot for another
party (besides the app and the hardware driver) to add more (uncoordinated)
signal processing makes this problem worse rather than better.
Regards,
Frank Yerrace
Microsoft Corporation
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of M'hand Boughias
Sent: Friday, October 12, 2012 1:22 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Issues in installing custom sAPO.
Hi,
I agree with Rob, Professional audio applications use ASIO or WASAPI in
exclusive mode in order to have a better latency, those two audio clients
bypass the APO.
M'hand.
On Fri, Oct 12, 2012 at 6:46 AM, Robert Bielik
<robert@xxxxxxxxxxx<mailto:robert@xxxxxxxxxxx>> wrote:
Hello Frank,
Frank Yerrace skrev 2012-10-11 22:02:
...Windows has no model for a third player to be involved...
What about the Microsoft Global FX which anyways need to be wrapped by any APO
? One of those could have had the option to control third party installed DMOs
for instance, and thus it would still be under full control of both
applications (through some WASAPI interface) and the user via sound control
panel. I can see no problem with such an approach.
Even just having these two controlling entities has caused problems in some
(important) user scenarios.
Any important scenario regarding professional audio applications pre-Vista
involves ASIO, and thus has nothing to do with APOs. With Vista++, things may
have changed a bit though, but I have a hard time getting my head around what
the problem is, so a short use-case to back that statement up would be
appreciated.
Thanks
/Rob
Frank Yerrace
Microsoft Corporation
-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>]
On Behalf Of Robert Bielik
Sent: Thursday, October 11, 2012 11:06 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] Re: Issues in installing custom sAPO.
Tim Roberts skrev 2012-10-11 19:07:
There is no clear and obvious path to implement general-purpose audio effects
products in Vista and beyond. That was mostly an intentional design decision.
There were so many poorly written effects in the pre-Vista world that it was
impossible to implement reliable professional audio applications.
Really ? Do you have any documentation to back up this statement ? Question is
not only for Tim but any Microsoft member of this list.
In the pre-Vista world there was only WaveCyclic and the impossibility for
reliable professional applications lay in the core of the WDM audio
implementation and more importantly, OS thread scheduling. On XP I cannot get
any reliable low latency app to work without setting process+thread to RT. Not
good, and possibly VERY unstable. With Vista++, WaveRT and reliable scheduling
with MMCSS has had that changed significantly, but that has *nothing* to do
with APOs or not.
And secondly, since the audio server functionality now is User Mode (and thus
the execution of any APO effects), as opposed to Kernel Mode in pre-Vista,
there is even lesser of a chance to mess things up! I think it is only a
"convenient" route taken by Microsoft.
/Rob
******************
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/
******************
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/
******************
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/
Other related posts:
