关于 OSX 的底层音频 Core Audio 输出方式的疑问

[liuxl8964]

之前我发的帖子『 OSX 系统真是鸡，数字光纤音频系统竟然不能调音量， win10 可以』
https://v2ex.com/t/242238
是我起的标题钓鱼引起撕逼是我的错，在这里道歉
我重新开个帖子，上个帖子不要再回复了

声音输出最基本路线是

解码»»数模转换»»播放设备
但是这个路线只是手机系统这种只有一个音源输出的才适用
桌面系统同一时间可以多音源同时输出，这就要把多个音频合成一个这个过程叫混音（ Audio Mixing ）
但混音是输出时候只能是一种声音 所以要经过采样率转换就是 SRC(Sample Rate Convertor ）
所以路线就变成了
解码»»SRC»»混音»»数模转换»»播放设备

先看看 Linux 情况

最初的一代经典 Sound Blaster 16 等声卡，本身都支持多路輸出混合
所以当时 linux/unix 的声卡驱动 OSS 『 Open Sound System 』把混音工作扔给了声卡
但是随着发展（主要是因为钱）新的声卡包括集成声卡把混音功能扔回了软件
就是因为 OSS 不支持混音才引起 linux 音频系统 10 多年的撕逼

先是 KDE/GNOME 分别出了声音服务 aRts 和 ESD 先做混音在把音频送给 OSS
但是问题来了，虽然大多数程序都能使用其中一个，但不能同时用两个，这是因为 OSS 的混音问题，甚至与另一个直接用 OSS 的程序冲突。为了解决这种状况出现了 SDL/libao 等封装库。

之后 OSS 开发人员走了闭源路线,业界震惊了，一些 Linux 开发人员就像 LiberOffice 那样决定创造另一个解决方案，但是他们没重写 OSS ，而是推出了一个全新的 API 也就是 ALSA(Advanced Linux Sound Architecture)，为了兼容又写了个 OSS 模拟器，然后大家纷纷发现用 OSS 模拟器效果比直接用 ALSA 好，但是用了模拟器又不能混音了 233 ，在 ALSA 把 OSSv3 剔除 linux 内核后， OSSv4 重新开源杀了回来，后来 ubuntu 和 Fedora 引入一个新的"先进的"的声音服务 PulseAudio ，这个混音质量好而且任何 API 都可以输出到 PulseAudio ，但是其实是只鸡延时巨大

再看看微软的情况

win 都是微软说了算自然没有 linux 的破事
xp 和之前用的是 MME(Multi Media Extension)和 DirectSound
而且当年 Intel 等五家公司出的 AC97 标准导致音频要 SCR 成 48khz 然后才输出默认是无法摆脱 SRC 影响的基本就是鸡，延时还高到爆炸 MME 要 200~500ms ， DirectSound 也要 50~100ms
vista 之后出了新的 API 叫 WASAPI
这个新 API 有 2 种模式共享模式和独占模式
共享模式和之前大体流程没变，但是有优化而且附加了一个系统级的混音器可以各程序单独调音量，相信大家都用过
而独占模式是为了音频损失和延时问题引入的，方法是直接跳过 SRC 和混音直接数模转换，但是代价就是瞬间变成手机系统只能一个音源发声，这个功能在声音设备高级选项卡里面设置。

回来看 MAC

大多数 PCHIFI 演示时候用的都是 MAC 演示的
而 OS X 早期设计时就是为专业音讯产业服务，是出了名的延时低，音质好。
1. 在引入混音后引起的 SRC 音质损失与延时问题 linux 撕逼这些年也没结果微软是直接阉割掉了才解决的，那 Core Audio 是如何在不阉割混响解决问题的？
2. 我在用播放软件的时候也有调音量功能，要是我一开始就没用最大音量，岂不是也损失了音频的位数和动态范围，这样情况为何苹果还在意数字音频音量调节会损失位数和动态范围？

[zhuang]

楼主说的大方向没有问题，只是需要进一步定量分析，所以结论会有所偏差。

关于延迟（ latency/delay ）：无论哪一种现代系统级音频处理，延迟都在 10ms 数量级以下，人耳对于音画不同步或者声音间断的容忍程度在 25~50 ms 左右。整个声音输出流程上的其他延迟才是大头。

关于动态范围（ dynamic range ），如果中间过程的位宽（ bit depth ）高于音频位宽一定程度，数字音量调节并不会损失动态范围。

[liuxl8964]

@zhuang 那 mac 是如何避免 SRC 的
或者是没法避免 SRC ，通过算法降低影响？

[jack345]

Core Audio 的 SRC 质量非常好，而且提供了 API 可以设置系统采样率从而避免 SRC ，也可以设置独占模式避免 mixing 。

[zhuang]

@liuxl8964
信号的角度上关心的是信噪比， SRC 是个数学问题，和数字音量调节一样并不会改变信噪比。
如果定量地来看 SRC 的“影响”，只有二进制表达的区别，而不具有音频重现意义上的差别。


PS
Win10 某个测试版之前也是数字输出，正式版推送驱动更新之后才启用了系统级的音量控制。这是个选择问题而不是技术问题。

[jarlyyn]

1.没有研究过 mac osx,准确的说我的 mac os x 是用来装 refind 的.个人觉得，混音并没有延迟到令人难以接受。

2.播放软件的音量调节和 eq,理论上和系统的混音的问题当然是一样的。只不过可能更专业点罢了。

我不觉得苹果数字输出不给调音量是个 feature ，是‘在意数字音频音量调节会损失位数和动态范围’。只不过是因为 mac os x 不是苹果主业务没花心思去做罢了。

而且我也不觉得数码调音量一定不如模拟调音量。数码的调音量的损失是可控的。模拟调音量并不是。

何况绝大部分音源本身的精细度也没到数字调音有损的那中精细程度。很多时候数字调音损失的本来也只是噪音而已。

另外，作为 oss,alsa,pluse 一路用过来的用户表示，对 pluse 印象最好。最初的 oss 还是 alsa 我的木耳朵都听的出破音来着。