Windows(不包括 Win8 )的音量控制界面是由一个单独进程实现的,并在用户点击任务栏图标后运行,这一点可通过任务管理器观察到(XP 下此进程为 sndvol32.exe )。在系统较忙碌时调用新进程所产生的资源开销应该是造成延迟的主要原因。
根据知友提供的经验,Windows 8 环境下「如果从Charm中调节音量反应倒是挺迅速的」。如此,有理由相信,音量调节的实现已经包含在 Charm 对应的进程内了,没有延迟也在情理之中。
而从传统桌面任务栏中打开音量控制界面,仍然会创建独立进程。如果此过程反应没有延迟,或许是由「预读」特性带来的影响(尚未可知)。
Linux 的情况则较为复杂,因桌面环境不同,其实现方式也各异,已知情况如:
KDE 桌面环境的音量控制是由进程 kmix 实现的,随系统开机启动。(感谢
@陶柯宇)
gnome 是 gnome-panel 里的 gnome-volume-control-applet ,随 gnome 一同加载。(感谢
@納米黑客)
---- 以下为答主的猜测 ----
OS X 的音量控制界面由「系统菜单」提供的内部控件实现。作为「桌面环境」(即 Finder )的一部分,「系统菜单」及其内部控件在开机登录桌面过程中便已加载。这就避免了为临时调用其他进程付出的代价。