使用.NET Core搭建分布式音频效果处理服务(一)需求、问题和解决方案的几个坑

简介: 最近公司需要在服务器上实现两个音频的合成及效果处理。 哇,乍一听功能很简单吧,就是将两个音频叠加,随便一个媒体处理软件几秒钟即可完成,但这仅仅只是针对单用户而言而已。其次,本来这种服务原本就不应该在服务器上面实现,为何? 流媒体处理是相当耗费服务器资源的,包括IO,CPU,bandwidth等等。

最近公司需要在服务器上实现两个音频的合成及效果处理。

哇,乍一听功能很简单吧,就是将两个音频叠加,随便一个媒体处理软件几秒钟即可完成,但这仅仅只是针对单用户而言而已。其次,本来这种服务原本就不应该在服务器上面实现,为何?

  1. 流媒体处理是相当耗费服务器资源的,包括IO,CPU,bandwidth等等。
  2. 服务器资源并不是毫无限制的,比如物理数量就会涉及到整体成本。
  3. 如果是一台机器维护到也简单,但实际运行场景远不止这么简单。
  4. 处理这类流媒体,时间上绝不是用毫秒级的方式来响应,这样就会衍生出更多的问题,比如一些莫名其妙的运行时错误。

如果在C/S模式下,完全可以采用client原生的在客户机上面进行流数据媒体处理,再将处理后的文件上传到指定的云存储位置(比如阿里云的OSS),这样对于服务器来说0压力,只是做个中间数据传递即可。一切就那么简单,不存在大并发问题,不存在扩展性问题,可两个关键问题又来了:

  1. 如果所有交互设备都使用统一的流媒体处理库进行处理(比如ffmpeg),那么,最终得到的效果文件将必定是一样的,可目前关键是目前IOS小组和ANDROID小组参数一样,得到的效果却完全不一样,IOS上有很明显的电流声和杂音(如果有高手指点一下,鄙人非常感谢,嘿嘿)。
  2. 在原生的软件(APP)上调用ffmpeg是可行的,在网页上怎么办?毕竟目前网页也可以实现录音的功能,比如微信API、Recorder.js,用户需要将自己的录制的声音进行一些效果处理的时候,那么网页将是无能为力的。

如上的最终效果不一致、平台功能没有100%覆盖问题,将又是这个产品实际的最大隐患,一致性和通用性并不只是针对技术要求,用户在产品的反馈上同样也需要一致性和通用性。因此,这样就需要服务器来统一处理这类功能需求和问题,如下几点优势(仅针对这个项目而言):

  1. 一致性。不论在哪种设备和操作系统(现在谁没有几台的智能设备啊),通过服务器统一反馈回来的音频文件试听效果均是一样的。
  2. 通用性。只需要统一的一个接口调用,不论PC,APP,H5网页,甚至包括嵌入式设备,只要能通信,那用户就能实现自己想要的音频合成效果。
  3. 不发烧。还有一个就是用户的可移动设备不用在因为处理某个音频而发烧烫手了,喝喝(对于部分低配的ANDROID手机)。

 

纯粹的点对点C/S模式,这里就不画图了,下一节我们开始慢慢的画饼o(∩_∩)o 哈哈。

 

感谢阅读

目录
打赏
0
0
0
0
8
分享
相关文章
简化 ASP.NET Core 依赖注入(DI)注册-Scrutor
Scrutor 是一个简化 ASP.NET Core 应用程序中依赖注入(DI)注册过程的开源库,支持自动扫描和注册服务。通过简单的配置,开发者可以轻松地从指定程序集中筛选、注册服务,并设置其生命周期,同时支持服务装饰等高级功能。适用于大型项目,提高代码的可维护性和简洁性。仓库地址:<https://github.com/khellang/Scrutor>
48 5
分布式锁服务深度解析:以Apache Flink的Checkpointing机制为例
【10月更文挑战第7天】在分布式系统中,多个进程或节点可能需要同时访问和操作共享资源。为了确保数据的一致性和系统的稳定性,我们需要一种机制来协调这些进程或节点的访问,避免并发冲突和竞态条件。分布式锁服务正是为此而生的一种解决方案。它通过在网络环境中实现锁机制,确保同一时间只有一个进程或节点能够访问和操作共享资源。
125 3
ASP.NET Core OData 9 正式发布
【10月更文挑战第8天】Microsoft 在 2024 年 8 月 30 日宣布推出 ASP.NET Core OData 9,此版本与 .NET 8 的 OData 库保持一致,改进了数据编码以符合 OData 规范,并放弃了对旧版 .NET Framework 的支持,仅支持 .NET 8 及更高版本。新版本引入了更快的 JSON 编写器 `System.Text.UTF8JsonWriter`,优化了内存使用和序列化速度。
104 0
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
57 11
在 ASP.NET Core 中创建 gRPC 客户端和服务器
本文介绍了如何使用 gRPC 框架搭建一个简单的“Hello World”示例。首先创建了一个名为 GrpcDemo 的解决方案,其中包含一个 gRPC 服务端项目 GrpcServer 和一个客户端项目 GrpcClient。服务端通过定义 `greeter.proto` 文件中的服务和消息类型,实现了一个简单的问候服务 `GreeterService`。客户端则通过 gRPC 客户端库连接到服务端并调用其 `SayHello` 方法,展示了 gRPC 在 C# 中的基本使用方法。
50 5
在 ASP.NET Core 中创建 gRPC 客户端和服务器
GraphQL 与 ASP.NET Core 集成:从入门到精通
本文详细介绍了如何在ASP.NET Core中集成GraphQL,包括安装必要的NuGet包、创建GraphQL Schema、配置GraphQL服务等步骤。同时,文章还探讨了常见问题及其解决方法,如处理复杂查询、错误处理、性能优化和实现认证授权等,旨在帮助开发者构建灵活且高效的API。
33 3
ASP.NET Core 中的速率限制中间件
在ASP.NET Core中,速率限制中间件用于控制客户端请求速率,防止服务器过载并提高安全性。通过`AddRateLimiter`注册服务,并配置不同策略如固定窗口、滑动窗口、令牌桶和并发限制。这些策略可在全局、控制器或动作级别应用,支持自定义响应处理。使用中间件`UseRateLimiter`启用限流功能,并可通过属性禁用特定控制器或动作的限流。这有助于有效保护API免受滥用和过载。 欢迎关注我的公众号:Net分享 (239字符)
33 0
|
2月前
|
Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出
本文深入探讨了Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出。文章还介绍了Redis在页面缓存、数据缓存和会话缓存等应用场景中的使用,并强调了缓存数据一致性、过期时间设置、容量控制和安全问题的重要性。
47 5
Android远程连接和登录FTPS服务代码(commons.net库)
Android远程连接和登录FTPS服务代码(commons.net库)
38 1
Windows Forms应用程序中集成一个ASP.NET API服务
Windows Forms应用程序中集成一个ASP.NET API服务
114 9
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等