音量控制计划

在Vista之前，所有对应用程序的控制都是系统级的——当你用wave volumn API改变音量的时候，你会同时改变硬件（声卡）的音量，因此会影响系统中所有的应用程序。这样做的问题在于，对于绝大部分应用程序来说，这是完全错误的行为。该行为是老的Windows 3.1音频架构的传统行为，在Windows 3.1的音频架构中，同一时间只允许一个应用程序播放声音，而在这种情况下，由于只有一个硬件音量，所以是有意义的。

在Win98的WDM音频驱动在发布之后，微软添加了内核模式音频混合器，但是他却把音量控制架构独立了出来。Windows API可以做的音量控制仍然是硬件音量控制，这么做的理由很简单：虽然每个应用程序确实需要单独的音量控制，但在Win98架构中，无法将一个独立的音频流和一个特定应用程序关联在一起，作为替换，音频流是单独处理的。

事实上，大部分应用程序确实需要单独控制他们音频流的音量，它们不想（也不需要）与其他应用程序混作一团，这其实是音频架构所导致的一个十分不好的副作用。

对于一些应用程序来说，我们是有解决方案的。例如，如果你使用的是DirectSound（或者DirectShow，实际上，DirectShow是基于DirectSound实现的），你可以把你的音频流放入一个辅助缓冲，因为DSound辅助缓冲是有自己的音量控制的，这样就可以有效地为每一个应用程序提供单独的音量控制。但这对于那些不使用DirectSound的应用程序没有任何帮助，它们只能依赖于调整硬件音量。

对于Vista而言，有一样东西被作为新的音频架构的一部分部署，那就是组件，叫做“音频策略”。策略引擎的一项任务就是跟踪哪个音频流属于哪个应用程序。

举办培训班5期次 在vista中，每个音频流都与一个\"音频会话\"（audio session）关联，音频会话则是与一个进程关联的（每一个进程可以有多个音频会话，音频会话则可以跨越多个进程，但是默认情况下，每个音频会话是当前进程中的音频流集合）

每个音频会话有它自己的音量控制，WASAPI会提供允许应用程序控制音频会话的音量的接口。音量控制API还包含了一个通知机制，这样的话，那些需要在音量控制改变时被通知到的应用程序可以实现这一点——这一机制允许应用程序了解其他人在何时更改音量。

这一切都很完美，但是这样的话，我们该处理那些已有的使用硬件音量控制，但是却又不想使用硬件音量控制的程序？

记住我所说的，所有的已有API都被移植，从而直接使用WASAPI。我们也把那些音量控制的API移植为使用WASAPI的音量控制接口。

我们也改变了mixerLine API来使用WASAPI。这稍微有点复杂，因为mixerLine API也需要我们定义一个音频设备的布局(topology)，但是我们已经定义了相对简单的布局，这一布局应该与现存的硬件技术相匹配（所有appcompat不应该是一个问题）

这么做的结果是：默认情况下，在Vista Beta 2中，我们将第一次为所有的应用程序提供每应用程序（per-application）的音量控制

有很小一部分应用程序将受到这一行为变化的影响，但是我们有一个机制来保证需要使用已有API调整硬件音量的应用程序将能够在Vista中顺利运行，而不用重写应用程序（如果你已经发现某个应用程序无法运转，你可以马上联系我，我将会把合适的人引入到这场讨论中）。

查看本文来源