Paul Davis，修复大型Linux音频问题的Areour的首席开发人员

这是对保罗·戴维斯(Paul Davis)的采访的第二部分，他是免费/libre数字音频工作站ardour的首席开发者。

在第一部分中，我们主要谈到了一切事物的热情。但现在是时候来谈谈一些与几乎每一位Linux音频应用程序的音乐制作用户相关的大事了。与上次一样，编辑后的成绩单如下所示。

三年前，在Linux音频会议上，您谈到了我们在Linux音频方面做的对和错的事情。你说的其中一件事是，Linux上的音频系统太复杂了，但是--我在这里可能引用错了--现在太晚了，我们可能不得不接受我们已经拥有的东西。你认为我们要花多少钱才能以一种更理智的方式重建Linux音频？你认为我们真的过了无可挽回的地步了吗？

我不记得你记得的确切的评论了。但有一件事我确实记得说过，可能就是这件事，那就是几年前我参与Linux桌面架构师团队时说过的话。大家讨论了在Linux桌面之年或其他什么年，我们应该对音频做些什么。

我在PulseAudio上给很多人指了指。因为即使我当时在做JACK，我觉得PulseAudio对消费者来说是更好的选择。它只是做了更多他们需要的事情。

我想…。我怀疑现在已经太晚了。我认为，如果你回头看看苹果在推出当时的OSX但后来重新命名为MacOS时所做的事情，他们完全改变了整个音频API。

没有人可以重新编译现有的软件。没有胶层，没有相容性。给开发人员的信息是：对不起，各位，你们必须重新实现这一点。苹果公司有足够的信心相信做这类软件的开发者会想要这么做，他们只是说事情就是这样。

但是Linux不像苹果平台那样工作。这里没有大棒。即使莱纳斯是这样认为的，现在我们也只是打算扔掉整个音频栈，完全替换掉整个音频栈"；…。即使这样，也不足以实现这一目标。

即使有人这么做了，也会有人走过来说，这是一个ALSA的兼容性库。因为人们用被取代的开放源码软件做到了这一点，而这个库仍然存在。

即使是在最初创建者的意愿下，PulseAudio也是如此。甚至没有人应该使用PulseAudio库，您应该使用ALSA，因为PulseAudio会伪装成ALSA设备。

因此，我不认为我们有足够大的大棒出现，只是说，好吧，我们学到了很多，但我们错了，我们只会再来一次。

现在，一个明显的问题是，嗯，也许有什么渐进的方式，也许它不会全部扔掉，也许它正在以更渐进的方式建立起来？

“管道钢丝”是一个有趣的项目。我很高兴它的主要开发者在过去的6个月里改变了他的方向。我认为他已经考虑到了罗宾和其他一些仍然参与其中的人提出的很多好的批评。

我认为，现在管道导线有更大的机会能够实现其所宣称的目标。它将成为PulseAudio和Jack的替代品。如果发生这种情况，如果它真的能够实现这些目标，我认为从某些角度来看，情况将变得更加干净。

将只有一台声音服务器。它将进行低延迟的专业音频音乐创作。它将处理来自浏览器的输出。它将处理桌面蜂鸣音和通知。

然而，这仍然留下了软件将使用什么API的问题。而这仍然是复杂性的一部分。

现在，这并不是Linux独有的复杂性。如果你在Windows上做音频软件，你会说我应该使用什么音频API呢？可以说，它至少和Linux一样差，甚至可能比Linux还差。这只是一大堆可能的答案。

因此，我所见过的唯一正确的操作系统是MacOS。我想说他们几乎每件事都做对了。而且他们没有做对的事情太小了，根本无关紧要。

有一个API，无论你是试图发出桌面嘟嘟声，还是正在试图编写数字音频工作站，都没有区别。只是起作用了。

如果你是一名用户，并且你想把胶水粘到设备上，就可以做成一个组合设备，只需点击几下鼠标即可。这是一个很棒的设计。

如果PipeWire达到了它为自己设定的技术目标，那么它可能会让我们在用户体验方面走得更远。但是我认为它仍然会在后台给软件开发人员留下一个空洞，那就是，好的，所以我想写一个音频软件。我该怎么办？"；。但至少这将由开发人员来解决。而且用户也不会遇到这样的情况，你知道，嗯，我正在使用热情，我的浏览器不能播放音频，诸如此类的东西。这样的问题就会消失。

现在，要像苹果对CoreAudio…所做的那样。他们实际上将大量内核功能移到了用户空间守护进程中。这给我带来了一点希望，也许你实际上不需要改变内核，也不需要改变ALSA。也许我们可以通过拥有正确的用户空间来做好这件事。

我认为我们只需拭目以待，看看PipeWire在另一年，也许一年半后会是什么样子。如果技术目标真的接近实现，那么我认为至少Linux上的音频用户体验将会显著改善。

杰克已经有5年没有再固执地热衷于爱情了。最近，我在IRC频道上听到了关于完全放弃对杰克的支持的可能性的讨论。现在，我知道你说这话时用了一堆笑脸，但你以前说过，你对杰克的结果不满意。那么这是怎么回事呢？你对杰克失望的主要原因是什么？你对热情和杰克的长期愿景是什么？

所以这里的背景故事是，是的，我是杰克的原创作者，它最初是由来自热情的代码创建的。我还是认为杰克是个非常酷的主意，如果我自己这么说的话。

但是…。它是为了解决一个非常特殊的需求而创建的，那就是Linux上缺少音频插件的插件API。其想法是，人们可以使用他们想要的任何工具、任何图形用户界面工具包、语言…来编写整个应用程序，而不是编写插件。然后我们就用插孔把它们连接在一起。这会很棒的。这意味着开发人员不必像使用插件和数字音频工作站那样进行协调。工作站开发人员不会经常收到像我这样的人发来的错误报告，它会崩溃。插件开发人员不会收到像“我不能在这个新DAW中使用您的插件”这样的电子邮件。那就太棒了！

杰克做到了这一点，这很棒，因为将音频和MIDI从一个程序发送到另一个程序的想法就像从程序发送到硬件或计算机…一样容易。我是说，这应该很容易做到。而杰克确实让这件事变得很容易做到。

JACK的一个问题是，它意味着您拥有一些人所说的模块化设置。你们有一群截然不同的程序在互相对话。您没有任何真正好的方法来一次保存所有程序的状态。我们有过尝试，他们还不错。但是，它仍然远不如使用一个在其中发生所有事情的单一程序那么方便。

这为许多用户创造了一个环境，我认为，这比他们真正想要的要复杂得多。即使对于很多新用户来说，JACK的基本概念也是如此，当他们不得不将此作为他们必须处理的第一件事时，就必须处理…。对他们来说，这并不是一个显而易见的概念。

他们习惯于在电脑上点击按钮，可能是在浏览器中，按钮的右边有一个小箭头，周围有一个圆圈，然后它会突然开始从扬声器中发出声音，这就是所有要发生的事情。

然后你会说，哦，不，不，这里有一个很酷的工具，它有一个补丁包，你必须设置参数和所有其他的东西。

现在，当你深入其中，当你真正参与到专业音频工作流程中时，你就会开始理解，就像，哦，天哪，这个插孔的东西实际上对某些东西来说真的很酷。但是对于一个刚开始使用这类软件的人来说，这真的不是你想要的。

有一些设计问题，一些我们从未真正做过的事情。几年前推出的元数据API已经解决了一些问题。例如，它允许您将漂亮的名称添加到杰克中的端口上，这样您就可以知道它们是什么。但我们从来没有真正解决过这样的问题，你知道，当你在那里有一块硬件时，通常在Windows和MacOS上至少可以通过一个名称来识别硬件。有时这些频道的名字也很好听。杰克几乎每时每刻都在工作，就是为了不做那件事。

我甚至不想让您知道您使用的是什么声卡，它就是所谓的系统。端口只有1、2、3、4、5、6、7、8、9…。"；。所以那就不在那里了。

还有其他问题，例如，我们从未解决过插孔传输机制中的循环问题。此外，杰克的线路中没有延迟，这意味着杰克可以报告延迟，但它对此无能为力。

所以这些都是阻碍我们前进的技术问题。然后，还有，某种程度上的，社区发展问题。早些时候，斯特凡纳·莱茨开始开发多进程版本的Jack。我当时觉得这是个好主意。它是用C++编写的，它将进行并行处理等，似乎完全适合沿着这条路线走下去。

重述过去的历史是没有意义的，但史泰芬后来成为JACK2的努力从未真正合并，它们从未与JACK1联合。它们在二进制级别上是兼容的，但它们为用户提供了不同的功能。这里有点乱七八糟的。

几年前，我把杰克项目的控制权交给了菲利普(科埃略)。我成功地完全不知道他在做什么和已经做了什么。我很乐意保持这种状态。所以杰克会做菲利普和项目的其他人想要做的事情。

你问起了艾杜尔和杰克·…。是的，那里有笑脸。我认为我们永远不会放弃对杰克的支持。我们确实继续遇到问题-最近，我认为在应用程序实际处理音频的地方进行线程化是一个疯狂的决定，在它的过程中，可以被告知像这样的事情：哦，你的一个端口刚刚断开连接"；或者"；有延迟变化"；。

当时我不同意斯特凡的看法，现在我更不同意了。但是，是的，我们会想出解决某些行为的办法的。我认为对杰克的支持不会有任何结果。

但我们现在通常会告诉新用户，你不必使用Jack。事实上，如果你不使用杰克，你最初的体验会容易得多。对于MIDI设备来说尤其如此。大多数使用JACK2的人必须经历一些额外的循环才能真正让硬件显示出来。然而，如果他们在Linux上使用ALSA后端，它就会正常工作。

所以杰克会在那里，我们会建议，并让越来越明显的是，杰克对你来说不是显而易见的东西。

有很多关于Areour和其他数字音频工作站之间的会话交换的讨论。我知道你对OMF和AAF非常不满。我知道你一直很不高兴，以至于你甚至推广了AATranslator，这是一个专有的项目文件转换软件，我想主要是因为它减轻了你的负担。但我最近听到罗宾和你对OpenTimelineIO(Otio)给予了肯定的评价，尽管这个项目更多的是与视频制作联系在一起，但几乎没有适用于Final Cut Pro X等软件的适配器。你认为Otio是前进的方向吗？

我认为在这一点上这仍然是一个很难回答的问题。我只简单地看了一下Otio的API和规范。与OMF或AAF相比，很难低估它有多大的进步。与这两个标准相比，这是一个巨大的进步。我的意思是，OMF甚至连一个标准都算不上--你甚至不能真正了解它的规格。我也不会说这两个，OMF和AAF，也主要与视频联系在一起。

我认为，从我的角度来看，这些格式的关键问题是，它们正常吗？AAF不正常，AAF疯了。AAF就是一个例子，说明了当你有三个委员会而不是一个委员会时会发生什么。当您有这样的想法时，嗯，我们不想指定文件系统是什么，文件是如何表示的，所以我们将使用一些Microsoft的东西，它允许您将文件系统放入文件中，这将是我们谈论文件的方式。这简直是疯了。

有好的迹象表明，奥蒂奥已经从这场混乱中迈出了一大步。因此，即使是考虑做AAF支持的一些最糟糕的因素也会消失。

我们也生活在这样一个时代，通常基于开源贡献者的心态承诺，无论如何，那个库和那个标准只会变得更好。

再说一次，我没有看得够详细，但另一部分是它们如何很好地代表了你作为会议格式所需要的音频方面。

如果您只表示完全直截了当的非线性编辑比特来匹配音频(如此文件资源来源)，我们需要这一比特，并且它会出现在时间线的这一点上，嗯，这是可以的，至少您可以为音频这样做。但实际上，要使其成为一种有用的音频会话格式，您需要更多的信息。

我不知道他们在这条路上到底走了多远。会话格式是否应该尝试表示插件，这是一个悬而未决的问题。这变得相当复杂，因为，你知道，如果你有AudioUnit插件，它们不能在任何地方运行，只能在MacOS上运行。

我对文件格式规范中表示的音频特定元素不够熟悉，无法真正知道它看起来有多好。

但如果他们至少能得到足够的支持，那么它就提供了一些希望，像Areour这样的音频应用程序可能会开始使用和支持这种格式。

这对于aaf来说是永远不会发生的，即使对于omf…也是如此。我不知道为什么，但是收割机对OMF的支持是开源的。所以我实际上在几年前做了一个[git]分支，增加了热情。事实证明，你知道，它可能支持所有OMF文件的三分之一。这只是另一个迹象，说明规范和标准化是多么令人震惊。

因此，我对此持谨慎乐观态度。我认为另一件有趣的事情是…。我听过很多人说，实际上，对于大多数用户来说，能够在工具之间移动会话的整个概念并不是一件真正的事情。特别是这个病毒之后，世界上还有多少录音棚。

你不会想简单地把你在这个录音棚里创建的会话带回家，然后用一个完全不同的工具来处理它。

是啊，你会很高兴的。但是，这种移民的故事并不经常发生。我认为它更相关的一个领域是与DAW来回的视频编辑。所以基本上在电影后期制作，甚至是制作过程中，…。在我看来，这似乎是一个更合理的案例，有一个人在视频方面工作，他们使用这个工具，然后我们让这个人用另一个工具集来处理音频。在这种情况下，很容易来回走动似乎是理所当然的。

这就是这种支持对我来说真正有意义的一个用例。没有意义的是什么？我用热情，但我的朋友用的是Cubase，我希望能和他来回交流。它就像…一样。

实际上说到插件…。你在LAC演讲中提到的另一件事是，U-He能够如此迅速地开发出斑马合成器，而我们只有这么多好的虚拟仪器，这意味着我们在做一些错误的事情。但现在有了一个更令人震惊的例子。VCV库现在有2,000多个模块。VCV Rack也是一款免费/libre软件，推出仅三年。LV2已经有十多年的历史了，我最后一次检查GitHub上大约有1000个相关的存储库，大多数插件都不容易安装，你必须编译其中的一些。你认为我们可以从VCV学到什么教训，我们如何切实地改善LV2生态系统？

首先我要说的是，我对Andrew[Belt]与VCV Rack所做的一切怀有难以置信的敬意。作为一个音频软件程序，它里面有一些让我困扰的技术问题。但是…。作为它的用户(我也是)，它是一款令人惊叹的软件。

但比软件更令人惊叹的是他围绕它建立的生态系统。也就是你刚才提到的。它有2000多个模块。获得这些模块的简便性，以及在程序中使用它们的简便性，完全是一个典范。以及该项目吸引了所有实际参与硬件模块合成甚至其他软件模块合成环境的人，甚至是对整个项目完全陌生的人的方式。

这简直令人难以置信，我对他的所作所为深表敬意。这让我有点嫉妒…。

作为这个程序的用户，我也非常高兴，因为它就是所有那些令人难以置信的模块，可以用来做真正伟大的事情。

这就是说，在简化模块方面，Andrew使用VCV Rack所做的事情中有一个元素要简单得多。也就是说，当您运行VCV机架的模块时，实际上就是在运行VCV机架的模块-与其他类型的VST插件或AU插件相比，VCV机架在很多很多方面都是一个插件。但它实际上是一个特定程序的插件，而不是一整套程序。因此，在一个简单的举动中，你已经消除了插件开发人员必须面对的大量问题，比如，我针对的是哪台主机？

事实上，Andrew也隐藏了很多特定于平台的东西。当然，仍然有人需要构建和编译插件。因此，想要尊重VCV Rack的三个平台传统-Linux、Windows和MacOS-的开发人员仍然必须努力面对这样一个事实，即他们必须构建它们以供人们使用。但是当您编写它们时，几乎没有特定于平台的东西。

因此，他所做的事情与现在越来越多的网络浏览器相差无几--它们是完整的开发环境。

VCV Rack是一个完全封闭的系统，我的意思是好的，这与它的libre/open方面没有什么不同。它就是这样，当您为VCV Rack编写一个模块时，这就是您要做的全部工作。

您不必考虑应该使用哪个图形工具包，在Windows和MacOS上如何处理关键部分有哪些细微的细节。所有这些都会烟消云散。您只需要使用一个非常简单的SDK，一个出色的模块图形设计。

..