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）的音量控制