亲宝软件园·资讯

展开

VISTA音量控制 [翻译]

人气:0
想了解VISTA音量控制 [翻译]的相关内容吗,在本文为您仔细讲解的相关知识和一些Code实例,欢迎阅读和指正,我们先划重点: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)的音量控制

加载全部内容

相关教程
猜你喜欢
用户评论