Thirteen
Thirteen
> [@WThirteen](https://github.com/WThirteen) 这部分我研究过，我大模型用了FASTGPT（不用设计上下文逻辑）,你别说用知识库了，就开启工作流模式，什么都不加节点，速度都要慢0.7-1.2秒，对于实时性很高要求的数字人来说，不合适，只能选用聪明的大模型+尽可能在系统初始提示词上做文章，要求不能太高，这就是豆包目前有ip形象，有语音通话，现在也有视频功能，就是没有开启虚拟ip形象数字人？大厂还搞不定这个？一是对口型确实影响打断和应答效率，即便asr调教的再好，也禁不住对推理口型拖后腿，二是体验提升微乎其微徒增算力。 > > 至于非得私有化查询知识库慢，还是多在界面交互或者动作编排切换上做文章吧，比如设计优雅的等待动画，或者给任务编排思考的动作衔接 > > 至于你那个还是换个思路吧，你调用了livetalking 就是先走了调用livetalking的tts，tts生成流式语音，然后驱动wav2lip，而wav2lip就是语音驱动口型的，本质还是得改进程序的底层架构，否则就只能用js检测麦克风音量让video标签音量变小的妥协办法 感谢大佬解惑
> 我这边也改好了，试过了很多方法，想要实时停主要还是得改process_frames方法同时减小batch_size，收到停止信号立即将视频流切到预设得静止视频，把音频切换到静音帧，tts部分的队列可以直接清空，推理和asr部分的队列还是尽量用task_id来标识一下每一帧的归属，打断后用过滤的形式丢掉老帧，尽量不要去清空或者修改存放推理生成视频帧队列，因为很可能导致音画不同步，改起来比较麻烦。 大佬们有没有出现内存溢出的情况，我现在出现这样的情况： 运行时间一长，服务器的内存被占满了。考虑是与livekit交互过程中，某一部分的资源未释放掉
@zhengyiwei1987 感谢大佬
@zhengyiwei1987 是的，写个脚本，检测这个进程的内存，达到一定的之后kill掉再启动这个进程。属于是没辙了
Currently, I'm also working on the LiveKit project and found a plugin called Dify. I hope it can be of help to you. https://pypi.org/project/livekit-plugins-dify/ Although I haven't managed to get...
> I agree that this needs to be changed as I am also having issues with it. I did get the container to run by adding these two lines to...
> > > I agree that this needs to be changed as I am also having issues with it. I did get the container to run by adding these two...
> > > > I agree that this needs to be changed as I am also having issues with it. I did get the container to run by adding these...