feat: 调整接口参数，调整语音编码方式为silk

[yuchiXiong]

关于issue #483 的代码改动，详细的改动说明在 issue 中有进行阐述。

1. 调整音频的编码方式从以前的AMR为PCM->SLIK
2. 调整一个上传音频前的请求参数

[TheSnowfield]

@takayama-lily 看看, 我覺得沒有太大問題. 但是我們已經花時間去寫了一個silk編碼庫
https://github.com/NekoRushX/node-silk , 我不是很確定是否要使用別的.

[TheSnowfield]

而且使用silk編碼器的原義是抛棄掉ffmpeg, 但是同時我們缺少mpeg-3解碼器,
合并此PR并不能達到計劃中的目的.

[yuchiXiong]

@takayama-lily 看看, 我覺得沒有太大問題. 但是我們已經花時間去寫了一個silk編碼庫 https://github.com/NekoRushX/node-silk , 我不是很確定是否要使用別的.

之前应该有看过这个实现，但当时没太弄明白silk编码的过程，所以尝试了下没成功，后来调好了就直接用sdk那个包了😂现在已经切换至node-silk实现了。

[yuchiXiong]

而且使用silk編碼器的原義是抛棄掉ffmpeg, 但是同時我們缺少mpeg-3解碼器, 合并此PR并不能達到計劃中的目的.

对这个挺感兴趣的，之前部署相关的应用的时候需要自行编译ffmpeg以支持amr的编码，感觉比较繁琐。但我本人没什么音频处理相关的经验，稍后会去看看有没有合适的库能够支持。

[yuchiXiong]

@TheSnowfield @takayama-lily @Zxilly

稍微尝试了下，目前在 yuchiXiong/oicq#b1e257df9671d2c84110efbb993bd9906441c665 上进行了修改，在本地完全卸载了 FFmpeg 以后也能进行常见音频格式的处理。

浏览器端提供了 AudioContext.decodeAudioData 方法来支持对常见音频格式的编码，在 Node 端我找到了 web-audio-api 来支持，根据描述，这个库按照 WAA(Web Audio API) 规范来实现了相对应的功能。

代码暂时放在一个单独的分支，因为我对音频处理没有什么经验，不知道这块的处理合不合适，希望大家能帮忙 review 一下，如果合适的话我再将其合并到该 PR 中。

[TheSnowfield]

非常感謝你對oicq做出的改進, 我稍後會和 @takayama-lily 開始測試。

[yuchiXiong]

非常感謝你對oicq做出的改進, 我稍後會和 @takayama-lily 開始測試。

好的~ 辛苦各位

[takayama-lily]

@yuchiXiong
目前无论是silk-sdk还是node-silk均采用阻塞模型，silk的转换还是比较耗时的，会阻塞主线程。
正在考虑修改node-silk为非阻塞，使其包装为Promise返回。如果有兴趣，可以参与此处的贡献。

[TheSnowfield]

@yuchiXiong 目前无论是silk-sdk还是node-silk均采用阻塞模型，silk的转换还是比较耗时的，会阻塞主线程。 正在考虑修改node-silk为非阻塞，使其包装为Promise返回。如果有兴趣，可以参与此处的贡献。

如果測試全部pass, 那先合并之後再考慮更新node-silk?
我覺得改造成Promise可以之後來説, 這個并不是一個很急著要去處理的事情.

[Zxilly]

可不可以用worker开一个专门的转换线程

[TheSnowfield]

可不可以用worker开一个专门的转换线程

我覺得完全可以

[yuchiXiong]

@yuchiXiong 目前无论是silk-sdk还是node-silk均采用阻塞模型，silk的转换还是比较耗时的，会阻塞主线程。 正在考虑修改node-silk为非阻塞，使其包装为Promise返回。如果有兴趣，可以参与此处的贡献。

抱歉我好像有点没太理解😭

目前 node-silk 实现中调用的 silkEncode/silkDecode 两个 C 实现的函数本身是阻塞的，基于 Promise 的包装应该只会使它们的调用时机被推移到事件循环下一次从微任务队列中取出它们，在那之后编解码的过程依然会阻塞主线程。我不太确定这是符合期望的。

我对 @Zxilly 提出的方案很感兴趣，明天或许可以尝试一下通过 child_process 或 worker_threads 等方案来进行包装，不知道是否能达到期望的效果。

另外不知道对这个 PR 的测试进展如何，我需要将 yuchiXiong/oicq#b1e257df9671d2c84110efbb993bd9906441c665 分支的代码合并到当前的 PR 分支吗🤔

[TheSnowfield]

別急x

[takayama-lily]

@yuchiXiong 目前无论是silk-sdk还是node-silk均采用阻塞模型，silk的转换还是比较耗时的，会阻塞主线程。 正在考虑修改node-silk为非阻塞，使其包装为Promise返回。如果有兴趣，可以参与此处的贡献。

抱歉我好像有点没太理解😭

目前 node-silk 实现中调用的 silkEncode/silkDecode 两个 C 实现的函数本身是阻塞的，基于 Promise 的包装应该只会使它们的调用时机被推移到事件循环下一次从微任务队列中取出它们，在那之后编解码的过程依然会阻塞主线程。我不太确定这是符合期望的。

意思就是要把C的实现改为非阻塞，实现回调函数或包装为Promise返回给JS调用者

[Zxilly]

翻了一下silk的代码，基本上没啥IO wait，改成非阻塞的实现性能上有意义吗？
如果是为了避免阻塞主event loop，另开一个线程应该更好点。弄成一个队列这样的形式。

[takayama-lily]

翻了一下silk的代码，基本上没啥IO wait，改成非阻塞的实现性能上有意义吗？ 如果是为了避免阻塞主event loop，另开一个线程应该更好点。弄成一个队列这样的形式。

就是为了避免阻塞事件循环。在JS中开进程或线程虽然也可以解决，只是不能做到开箱即用，开销也会更大，不是一劳永逸的解决方案。所以考虑完善silk库以后再引入