VISTA音量控制 [翻译]
作者：
VISTA音量控制 [翻译]
原文：https://blogs.msdn.com/larryosterman/archive/2005/12/15/504158.aspx
作者：larryosterman
翻译：Tony Qu (来自BluePrint翻译团队)
在Vista之前，所有对应用程序的控制都是系统级的——当你用wave volumn API改变音量的时候，你会同时改变硬件（声卡）的音量，因此会影响系统中所有的应用程序。这样做的问题在于，对于绝大部分应用程序来说，这是完全错误的行为。该行为是老的Windows 3.1音频架构的传统行为，在Windows 3.1的音频架构中，同一时间只允许一个应用程序播放声音，而在这种情况下，由于只有一个硬件音量，所以是有意义的。
在Win98的WDM音频驱动在发布之后，微软添加了内核模式音频混合器，但是他却把音量控制架构独立了出来。Windows API可以做的音量控制仍然是硬件音量控制，这么做的理由很简单：虽然每个应用程序确实需要单独的音量控制，但在Win98架构中，无法将一个独立的音频流和一个特定应用程序关联在一起，作为替换，音频流是单独处理的。
事实上，大部分应用程序确实需要单独控制他们音频流的音量，它们不想（也不需要）与其他应用程序混作一团，这其实是音频架构所导致的一个十分不好的副作用。
对于一些应用程序来说，我们是有解决方案的。例如，如果你使用的是DirectSound（或者DirectShow，实际上，DirectShow是基于DirectSound实现的），你可以把你的音频流放入一个辅助缓冲，因为DSound辅助缓冲是有自己的音量控制的，这样就可以有效地为每一个应用程序提供单独的音量控制。但这对于那些不使用DirectSound的应用程序没有任何帮助，它们只能依赖于调整硬件音量。
对于Vista而言，有一样东西被作为新的音频架构的一部分部署，那就是组件，叫做“音频策略”。策略引擎的一项任务就是跟踪哪个音频流属于哪个应用程序。
在vista中，每个音频流都与一个"音频会话"（audio session）关联，音频会话则是与一个进程关联的（每一个进程可以有多个音频会话，音频会话则可以跨越多个进程，但是默认情况下，每个音频会话是当前进程中的音频流集合）
每个音频会话有它自己的音量控制，WASAPI会提供允许应用程序控制音频会话的音量的接口。音量控制API还包含了一个通知机制，这样的话，那些需要在音量控制改变时被通知到的应用程序可以实现这一点——这一机制允许应用程序了解其他人在何时更改音量。
这一切都很完美，但是这样的话，我们该处理那些已有的使用硬件音量控制，但是却又不想使用硬件音量控制的程序？
记住我所说的，所有的已有API都被移植，从而直接使用WASAPI。我们也把那些音量控制的API移植为使用WASAPI的音量控制接口。
我们也改变了mixerLine API来使用WASAPI。这稍微有点复杂，因为mixerLine API也需要我们定义一个音频设备的布局(topology)，但是我们已经定义了相对简单的布局，这一布局应该与现存的硬件技术相匹配（所有appcompat不应该是一个问题）
这么做的结果是：默认情况下，在Vista Beta 2中，我们将第一次为所有的应用程序提供每应用程序（per-application）的音量控制
作者：larryosterman
翻译：Tony Qu (来自BluePrint翻译团队)
在Vista之前，所有对应用程序的控制都是系统级的——当你用wave volumn API改变音量的时候，你会同时改变硬件（声卡）的音量，因此会影响系统中所有的应用程序。这样做的问题在于，对于绝大部分应用程序来说，这是完全错误的行为。该行为是老的Windows 3.1音频架构的传统行为，在Windows 3.1的音频架构中，同一时间只允许一个应用程序播放声音，而在这种情况下，由于只有一个硬件音量，所以是有意义的。
在Win98的WDM音频驱动在发布之后，微软添加了内核模式音频混合器，但是他却把音量控制架构独立了出来。Windows API可以做的音量控制仍然是硬件音量控制，这么做的理由很简单：虽然每个应用程序确实需要单独的音量控制，但在Win98架构中，无法将一个独立的音频流和一个特定应用程序关联在一起，作为替换，音频流是单独处理的。
事实上，大部分应用程序确实需要单独控制他们音频流的音量，它们不想（也不需要）与其他应用程序混作一团，这其实是音频架构所导致的一个十分不好的副作用。
对于一些应用程序来说，我们是有解决方案的。例如，如果你使用的是DirectSound（或者DirectShow，实际上，DirectShow是基于DirectSound实现的），你可以把你的音频流放入一个辅助缓冲，因为DSound辅助缓冲是有自己的音量控制的，这样就可以有效地为每一个应用程序提供单独的音量控制。但这对于那些不使用DirectSound的应用程序没有任何帮助，它们只能依赖于调整硬件音量。
对于Vista而言，有一样东西被作为新的音频架构的一部分部署，那就是组件，叫做“音频策略”。策略引擎的一项任务就是跟踪哪个音频流属于哪个应用程序。
在vista中，每个音频流都与一个"音频会话"（audio session）关联，音频会话则是与一个进程关联的（每一个进程可以有多个音频会话，音频会话则可以跨越多个进程，但是默认情况下，每个音频会话是当前进程中的音频流集合）
每个音频会话有它自己的音量控制，WASAPI会提供允许应用程序控制音频会话的音量的接口。音量控制API还包含了一个通知机制，这样的话，那些需要在音量控制改变时被通知到的应用程序可以实现这一点——这一机制允许应用程序了解其他人在何时更改音量。
这一切都很完美，但是这样的话，我们该处理那些已有的使用硬件音量控制，但是却又不想使用硬件音量控制的程序？
记住我所说的，所有的已有API都被移植，从而直接使用WASAPI。我们也把那些音量控制的API移植为使用WASAPI的音量控制接口。
我们也改变了mixerLine API来使用WASAPI。这稍微有点复杂，因为mixerLine API也需要我们定义一个音频设备的布局(topology)，但是我们已经定义了相对简单的布局，这一布局应该与现存的硬件技术相匹配（所有appcompat不应该是一个问题）
这么做的结果是：默认情况下，在Vista Beta 2中，我们将第一次为所有的应用程序提供每应用程序（per-application）的音量控制