使用RTMFP与操纵语音音频进行实时语音聊天

Question

我们正在使用Cumulus构建一个实时RTMFP语音聊天应用程序。尽管使用NetStreams进行基本语音传输非常简单，但我们遇到了一个大问题：

似乎没有办法操纵NetStream发送的麦克风数据，也不是操纵数据的方式NetStream在播放之前收到。

但是，这正是我们所需要的。我们不想传送正常的麦克风录制的音频，但是先调出它，然后发送它，然后播放它。或者先发送它，然后播放它，然后播放它。但似乎整个音频录制，speex编码，speex解码和音频播放完全封装在NetStream类中。

达到我们想要的（和所有的人都完全去除的NetStream）的唯一途径似乎是：

1. 发送原始音调的音频数据。这确实有用，但是当然需要发送大量数据，并且可能无法在我们的本地局域网测试之外工作得足够快。

2. 音调音频数据，使用现有的闪存编码器转换为ogg/mp3，发送，解码ogg/mp3和播放。但是这意味着要对从麦克风接收到的每个样本数据包进行编码，添加标题等等。因此，与原始音频数据相比，这甚至不会产生太大的好处。

   2.1。如果存在用于闪存的Speex编码器/解码器，这实际上是一个好方法。但具有讽刺意味的是，除了内置的一个（用于在NetStreams中对音频进行编码/解码），无法明确使用。是的，非常感谢没有提供它，Adobe ...

3. 发送数据到积云服务器，沥青（并可能转换）在那里，并发送给收件人。这甚至可能不会比1快得多，并且还会丢弃RTMFP，P2P通信的确切益处。

有没有办法解决这个问题，将我比这里列出可能的方式将其传递给NetStream之前，实际操作麦克风数据的那些工作得更好？

Answer 1

为了获得可行性，音频数据必须以压缩格式转换，原始数据代表大量数据。 我认为第二种选择是更好的;-)

我已经开发了闪存中的ogg vorbis解码器/编码器，在使用炼金术时，它总是消耗不到10％的CPU！ 完全可能。

如果您更喜欢speex格式，我认为通过一贯的努力，可以在构建炼金术的speex代码时获得相同的结果。

如果我能给你更多的进一步信息，请联系我cumulus.dev@gmail.com ;-)