我想通过网络发送声音。我已设法通过PULSE_SERVER=$IP在客户端上设置环境变量来实现此目的。在服务器端，我运行paprefs并启用了对全局声音设备的网络访问。
这几乎是开箱即用的，并且对我来说很有意义 - 我只是将声音转发到远程套接字而不是本地套接字。
然而，在各种教程中，一般设置似乎也在pulseaudio客户端上运行一个实例：
- https://manurevah.com/blah/en/p/PulseAudio-Sound-over-the-network
- https://www.willprice.org/2013/05/10/pulseaudio-network-streaming.html
有人能解释一下这两种设置之间的区别吗？优点和缺点是什么？
答案1
据我了解：
拥有本地服务器可让您使用不同的传输方式（pulseaudio 具有模块的任何传输方式 - 例如，您可以加载用于压缩音频的 RTP 或 AirPlay 模块），而 libpulse 本身仅限于未压缩的“本机” PulseAudio 协议。
有了本地服务器，您就可以透明地在本地和远程输出之间切换。您可以动态添加远程接收器，而无需使用新的 $PULSE_SERVER 设置重新启动程序。我认为您甚至可以使用 module-combine-sink 通过两个设备输出相同的音频（如果它可以应对延迟差异的话）。
就此而言，本地服务器甚至可以通过 Avahi（mDNS）自动发现远程接收器 - 您启用它后，它们就会显示在列表中。
拥有本地服务器可让您选择哪个设备应该运行 CPU 密集型过滤器（均衡器、效果模块等）——如果流式传输到 Raspberry Potato，您可以在本地加载它们，而不是让接收器完成所有工作。
拥有本地服务器也可能提高程序性能，因为某些 libpulse 操作会接收本地响应，而不必等待远程服务器。（话虽如此，我不确定实际上哪些操作会受到影响。但我认为当服务器宕机时，它可能会产生非常明显的差异。）
这类似于使用 Xpra 或 RDP/VNC 与原始 X11 转发。在“远程”端拥有中间 X 服务器使其能够更智能地了解网络状况（例如，当检测到延迟时，Xpra 会动态启用 JPEG 压缩），提供错误恢复和按需分离/重新连接，甚至 GPU 加速；而直接将 $DISPLAY 指向另一台主机意味着传输巨大的原始像素图，并且每次连接中断时都会崩溃和烧毁。