一、概述
pyannote.audio
直接能够进行 Speaker Verification
、Speaker Diarization
等任务,但尚未提供 Speaker Identification
。 本文简述如何基于 pyannote.audio 进行 Speaker Identification。
在有 CPU
和 GPU
参与的一种运算中,比如深度学习推理,CPU 需要预处理数据,然后交给 GPU 处理,最后 CPU 对 GPU 的运算结果进行后处理。
在整个过程中都是 FIFO
,即数据 ABC 按顺序输入,也需要按 A’B’C’ 顺序输出。
如果采用同步阻塞的方式,在 CPU 预处理时 GPU 处于空闲状态,GPU 运算时 CPU 后处理处于空闲状态并且也不能进行后续数据的预处理。这样影响整体的吞吐。
期望是 GPU 运算时,CPU 可以同时进行数据预处理和后处理。这是典型的单生产者单消费者模式。
在两个线程之间传递数据时,为确保线程安全,可以在一个线程每次 malloc
或 new
申请内存,在另一个线程 free
或 delete
。为了避免频繁的内存分配和释放,需要使用到内存池。
本文描述采用有界队列实现内存池,适用场景和限制:
Mediasoup
主要提供了 3 个库和 1 个 demo。
库名 | 说明 |
---|---|
mediasoup | 主要包含三部分。一是 worker 可执行程序,由 C++ 实现,是本系列分析的重点;二是 Node 库,由 TypeScript 实现;三是 Rust 库,和 Node 的主要不同在于它没有以进程方式而是以静态库方式使用 mediasoup-worker。 |
mediasoup-client | Web 客户端库。TypeScript 实现。 |
libmediasoupclient | Native 客户端库。C++ 实现。 |
mediasoup-demo | 官方 Demo。 |
Examples | 各种示例。 |
网络上对 mediasoup 的 Node.js
层——准确说是对官方的 mediasoup-demo
的源码分析比较多,对于 mediasoup-client
和 mediasoup-worker
(之后简 worker) 等的源码详细分析相对较少。本人之前有将 GB28281
集成进 mediasoup 的想法并验证了可行性,以及使用 .Net
重新实现过 Node.js 层(含 mediasoup-client 和 mediasoup-demo),对 worker 的源码进行过比较粗略地浏览。最近基于想要弥补一些比较模糊的认知,并且 mediaoup 本身也在进化,故就再做了一次源码的梳理。
至于 mediasoup 是什么、能做什么、与其他 SFU 相较而言的优缺点、Demo 如何运行、为什么不用单一语言来实现等等讨论不是本系列关注的重点。
有如下两种情况的 Nginx
端口映射:一是比如将 8001-8010 这 10 个端口映射到本机的 18001-18010 这 10 个 HTTP/HTTPS
服务上;二是反过来,比如将 10080,18001-18010 这 11 个端口映射到本机的 80,8001-8010 这 11 个HTTP/HTTPS
服务上。
当然,对于 HTTP
服务,用 iptables
也是能够实现的。但是要做同一个域名下的批量端口的 SSL
反向代理的话,最直接的方式是在 nginx.conf
中写多个 server
配置块。这样会导致 nginx.conf
的内容过多。
如果批量端口如上面描述的那样有规律可循,则可以通过 server_port
变量来简化 nginx.conf
。