省流结论：理想情况下走windows系统api的几乎没影响，但有些情况下可能不行。

首先一般来说音频链路有三个音量：软件音量、系统音量和外部音箱/耳机旋钮的音量。

• wasapi下：软件音量和系统音量谁高谁低几乎没有影响，但软件+系统低音量配合外部音箱旋钮高音量则可能会损失音质(取决于声卡，但现代声卡一般都支持24bit输出所以影响基本可以忽略)
• 其他音频接口：使用16bit链路处理时可能会有较多损失

在后来的windows，也就是最高票说的vista以后，windows提供了wasapi。默认情况下只要软件正经用wasapi就不会有影响，但也有不正经软件。

常见的音频api除了wasapi还有direct sound、waveout，第三方还有asio。direct sound或者waveout就可能有更大的损失。

从体感而言，Windows下B站的网页版可能没有走这些系统音频接口，或者预处理过程有些粗糙，体感音量10%以下就会难以听清，暂时不清楚其如何实现的音频。

一个比喻

我们都知道，计算机通常保存的是整数，音频文件是0-65535之间的整数构成的点序列。为了简单起见，我们把数字限制在0-99的整数。

假如我们原来的音频5个点是66 77 44 88 33，那么10%音量，如果整个过程只允许整数，按照纯整数的处理方式，除以10以后就成了6 7 4 8 3，这样就会有较大失真。

如果更极端一点，取1%音量，那就会变成1 1 0 1 0，声音直接成方波了。更极端一点，取0.5%音量，那就全都变成0了。

Windows设计的时候考虑到了这一点，所以处理的时候会先扩展成32比特浮点数，如果套用上面的例子，windows相当于允许你使用0.000-99.999。通过提供小数点后的部分，保证你调整音量后波形不失真。

还是上面的5个点的音频例子，转换后的结果是66.000 77.000 44.000 88.000 33.000。

这时候取10%那就成了6.600 7.700 4.400 8.800 3.300，即便是取1%音量也是0.660 0.770 0.440 0.880 0.330——采样点之间的数值比例并没有因为量化而损失，波形并没有因为缩放失真。

但如果你非要特别极端，取0.01%的音量，那Windows也救不了你了，会变成0.006 0.007 0.004 0.008 0.003，那即便是音箱用了10000倍音量保证最后输出音量一致，波形的数字关系也损坏了。

结论

只要是较为现代的音频系统，通常都会对音量和频率做较多的处理。

但有些网页或者app就不一定是这样处理的，也可能会用简单粗暴的整数处理方式？

很显然微软的工程师并不是傻子，但不代表所有场景下都有聪明的工程师。