服务、流式传输和使用大型音频文件的基本架构，以最大限度地减少客户端资源消耗和延迟
Basic architecture to serve, stream and consume large audio files to minimize client-side resource consumption and latency
我正在尝试构建一个需要以某种方式实现音频流功能的 Web 应用程序。只是为了给你们一些背景：它被设计成一个纯粹的听觉 experience/game/idkhowtocallit，有许多不同的声音资产，其长度和文件大小各不相同。要提供的声音资产将包括环境声音、谈话的口语片段，以及长音乐集（最多几个小时）。为什么我认为我不能将这些音频文件托管在某些服务器或 CDN 上并从那里提供服务，因为声音资产需要动态获取和播放（取决于用户交互）并尽可能即时.
- 最重要的是，整体上使用较大的文件（如音乐集和长环境循环）对我来说似乎根本不是客户端友好的（移动网络上使用的数据消耗和客户端内存使用).
- 另外，如果没有任何缓冲或流媒体机制，客户端将无法在这些文件完全下载之前开始播放这些文件，对吗？这会增加高延迟的问题。
我尝试在线研究如何正确实施良好的基础架构以将更大的音频文件流式传输到服务器端的客户端，并找到了 HLS 和 MPEG-DASH。我有一些使用网络播放器使用 HLS 播放器的经验，如果我理解正确，我会使用某种一次性转换过程（在文件上传时或之后）将文件分成块并创建播放列表，然后就可以了通过 HTTP 提供这些文件。据我了解，MPEG-DASH 的过程应该或多或少是相同的。我对这两种技术的问题是，如果不重新发明轮子，我真的找不到任何关于如何实现 JavaScript/TypeScript 客户端（特别是使用网络音频 API）的文档。我最好的猜测是使用 hls.js 之类的东西并将 HLS 流绑定到新创建的音频元素，并使用这些元素在我的 Web 音频图中创建 AudioSources。我有多远？我试图至少了解最佳实践。
总结一下我非常希望能弄清楚以下内容：
- HLS 或 MPEG-DASH 真的是可行的方法吗？或者我是否缺少具有良好库的更基本的分块文件流机制？
- 从理论上讲，我将如何限制客户端提前下载的块数量以节省客户端资源，这是我最关心的问题之一？
- 我也在研究托管服务，但认为其中大多数专门用于托管播客（较少但非常大的文件）。有人对我是否可以使用这些服务来托管和流式传输可能从很小到相当大的 1000 个文件有意见吗？
非常感谢所有愿意帮助我的人。非常感谢。
Why I think I won't be able to just host these audio files on some server or CDN and serve them from there is, because the sound assets will need to be fetched and played dynamically (depending on user interaction) and as instantly as possible.
您的长 运行 环境声音可以使用普通 HTMLAudioElement 播放。当您播放它们时，由于它们必须开始流式传输，因此在它们开始之前可能会有一点延迟，但请注意，浏览器通常会预取元数据，甚至可能是媒体数据的开头。
对于延迟很关键的短声音（如 one-shot 用户交互音效），将它们加载到带有网络音频的缓冲区中 API 进行播放。您将无法流式传输它们，但它们会尽可能立即播放。
Most importantly, consuming larger files (like the music sets and long ambient loops) as a whole doesn't seem to be client-friendly at all to me (used data consumption on mobile networks and client-side memory usage).
如果你想播放音频，你自然要下载那个音频。您无法播放未以某种方式加载的内容。如果您使用音频元素，您下载的内容不会比正在播放的内容多多少。而且，下载主要是 on-demand.
Also, without any buffering or streaming mechanism, the client won't be able to start playing these files before they are downloaded completely, right? Which would add the issue of high latencies.
如果您使用音频元素，浏览器会处理所有的缓冲，而不是为您处理。你不用担心。
I've tried to do some online research on how to properly implement a good infrastructure to stream bigger audio files to clients on the server side and found HLS and MPEG-DASH.
如果您只流式传输单一比特率（对于音频通常很好）并且您不流式传输实时内容，那么这里没有必要使用 HLS 或 DASH。
Would HLS or MPEG-DASH really be the way to go or am I missing a more basic chunked file streaming mechanism with good libraries?
浏览器将发出远程 HTTP 请求以从常规静态媒体文件中获取所需的数据。您不需要做任何特别的事情来流式传输它。只需确保您的服务器配置为处理远程请求......大多数人应该能够立即执行此操作。
How - theoretically - would I go about limiting the amount of chunks downloaded in advance on the client side to save client-side resources, which is one of my biggest concerns?
如果您使用音频元素，浏览器会为您执行此操作。此外，数据保存设置和检测到的连接速度可能会影响浏览器是否 pre-fetches。关键是，您不必为此担心。你只会使用你需要的东西。
只需确保尽可能高效地压缩媒体以获得所需的音频质量。使用好的编解码器，例如 Opus 或 AAC。
I was looking into hosting services as well, but figured that most of them are specialized in hosting podcasts (fewer but very large files). Has anyone an opinion about whether I could use these services to host and stream possibly 1000s of files with sizes ranging from very small to rather large?
大多数常规 HTTP CDN 都可以正常工作。
给您的最后一条提示...提防 iOS 和 Safari。由于 Apple 的限制性政策，iOS 下的所有浏览器实际上都是 Safari。 Safari 无法一次播放多个音频元素。如果您使用 Web Audio API，您将拥有更大的灵活性，但是 Web Audio API 没有真正的流式传输。您可以使用媒体元素源节点，但这会破坏锁定屏幕元数据，并且在某些旧版本 iOS 上完全不起作用。长话短说；博士； Safari 对于网络上的音频几乎毫无用处，Apple 的商业惯例已经打破了任何替代方案。
我正在尝试构建一个需要以某种方式实现音频流功能的 Web 应用程序。只是为了给你们一些背景：它被设计成一个纯粹的听觉 experience/game/idkhowtocallit，有许多不同的声音资产，其长度和文件大小各不相同。要提供的声音资产将包括环境声音、谈话的口语片段，以及长音乐集（最多几个小时）。为什么我认为我不能将这些音频文件托管在某些服务器或 CDN 上并从那里提供服务，因为声音资产需要动态获取和播放（取决于用户交互）并尽可能即时.
- 最重要的是，整体上使用较大的文件（如音乐集和长环境循环）对我来说似乎根本不是客户端友好的（移动网络上使用的数据消耗和客户端内存使用).
- 另外，如果没有任何缓冲或流媒体机制，客户端将无法在这些文件完全下载之前开始播放这些文件，对吗？这会增加高延迟的问题。
我尝试在线研究如何正确实施良好的基础架构以将更大的音频文件流式传输到服务器端的客户端，并找到了 HLS 和 MPEG-DASH。我有一些使用网络播放器使用 HLS 播放器的经验，如果我理解正确，我会使用某种一次性转换过程（在文件上传时或之后）将文件分成块并创建播放列表，然后就可以了通过 HTTP 提供这些文件。据我了解，MPEG-DASH 的过程应该或多或少是相同的。我对这两种技术的问题是，如果不重新发明轮子，我真的找不到任何关于如何实现 JavaScript/TypeScript 客户端（特别是使用网络音频 API）的文档。我最好的猜测是使用 hls.js 之类的东西并将 HLS 流绑定到新创建的音频元素，并使用这些元素在我的 Web 音频图中创建 AudioSources。我有多远？我试图至少了解最佳实践。
总结一下我非常希望能弄清楚以下内容：
- HLS 或 MPEG-DASH 真的是可行的方法吗？或者我是否缺少具有良好库的更基本的分块文件流机制？
- 从理论上讲，我将如何限制客户端提前下载的块数量以节省客户端资源，这是我最关心的问题之一？
- 我也在研究托管服务，但认为其中大多数专门用于托管播客（较少但非常大的文件）。有人对我是否可以使用这些服务来托管和流式传输可能从很小到相当大的 1000 个文件有意见吗？
非常感谢所有愿意帮助我的人。非常感谢。
Why I think I won't be able to just host these audio files on some server or CDN and serve them from there is, because the sound assets will need to be fetched and played dynamically (depending on user interaction) and as instantly as possible.
您的长 运行 环境声音可以使用普通 HTMLAudioElement 播放。当您播放它们时，由于它们必须开始流式传输，因此在它们开始之前可能会有一点延迟，但请注意，浏览器通常会预取元数据，甚至可能是媒体数据的开头。
对于延迟很关键的短声音（如 one-shot 用户交互音效），将它们加载到带有网络音频的缓冲区中 API 进行播放。您将无法流式传输它们，但它们会尽可能立即播放。
Most importantly, consuming larger files (like the music sets and long ambient loops) as a whole doesn't seem to be client-friendly at all to me (used data consumption on mobile networks and client-side memory usage).
如果你想播放音频，你自然要下载那个音频。您无法播放未以某种方式加载的内容。如果您使用音频元素，您下载的内容不会比正在播放的内容多多少。而且，下载主要是 on-demand.
Also, without any buffering or streaming mechanism, the client won't be able to start playing these files before they are downloaded completely, right? Which would add the issue of high latencies.
如果您使用音频元素，浏览器会处理所有的缓冲，而不是为您处理。你不用担心。
I've tried to do some online research on how to properly implement a good infrastructure to stream bigger audio files to clients on the server side and found HLS and MPEG-DASH.
如果您只流式传输单一比特率（对于音频通常很好）并且您不流式传输实时内容，那么这里没有必要使用 HLS 或 DASH。
Would HLS or MPEG-DASH really be the way to go or am I missing a more basic chunked file streaming mechanism with good libraries?
浏览器将发出远程 HTTP 请求以从常规静态媒体文件中获取所需的数据。您不需要做任何特别的事情来流式传输它。只需确保您的服务器配置为处理远程请求......大多数人应该能够立即执行此操作。
How - theoretically - would I go about limiting the amount of chunks downloaded in advance on the client side to save client-side resources, which is one of my biggest concerns?
如果您使用音频元素，浏览器会为您执行此操作。此外，数据保存设置和检测到的连接速度可能会影响浏览器是否 pre-fetches。关键是，您不必为此担心。你只会使用你需要的东西。
只需确保尽可能高效地压缩媒体以获得所需的音频质量。使用好的编解码器，例如 Opus 或 AAC。
I was looking into hosting services as well, but figured that most of them are specialized in hosting podcasts (fewer but very large files). Has anyone an opinion about whether I could use these services to host and stream possibly 1000s of files with sizes ranging from very small to rather large?
大多数常规 HTTP CDN 都可以正常工作。
给您的最后一条提示...提防 iOS 和 Safari。由于 Apple 的限制性政策，iOS 下的所有浏览器实际上都是 Safari。 Safari 无法一次播放多个音频元素。如果您使用 Web Audio API，您将拥有更大的灵活性，但是 Web Audio API 没有真正的流式传输。您可以使用媒体元素源节点，但这会破坏锁定屏幕元数据，并且在某些旧版本 iOS 上完全不起作用。长话短说；博士； Safari 对于网络上的音频几乎毫无用处，Apple 的商业惯例已经打破了任何替代方案。