问题背景
使用TS3AuBot机器人播放歌曲时，发现时常会出现1~2秒的声音卡顿，机器人与TS服务器分别部署于不同的ECS服务器，遂分别进行测试排查。
测试过程
针对机器人测试：将机器人放置于其他TS服务器播放歌曲进行测试，未发现语音卡顿问题。
针对服务器测试：
测试一：将个人音频输入模式修改为“持续传输”，关闭降噪等选项，使用Soundpad等软件于个人PC上播放歌曲，使用其他电脑(或邀请他人)监听或录制音频情况，发现卡顿现象。
测试二：观察各个用户端的连接信息，发现网络延迟时常出现异常波动，判断卡顿现象发生于所有人，问题与TS服务器相关。
问题排查
检查系统日志（/var/log/message）发现有如下记录频繁出现：
Dec 19 05:29:27 [localhost] kernel: device eth0 entered promiscuous mode
Dec 19 05:29:28 [localhost] kernel: device eth0 left promiscuous mode
Dec 19 05:31:30 [localhost] kernel: device eth0 entered promiscuous mode
Dec 19 05:31:31 [localhost] kernel: device eth0 left promiscuous mode前后分别指eth0网卡进入了混杂模式和退出了混杂模式，大约每两分钟重复一次。
混杂模式是网卡的一种工作模式，工作在混杂模式下的网卡接收所有的流过网卡的帧，信包捕获程序就是在这种模式下运行的。一般情况下并不会影响网卡的正常工作，多在网络监听工具上使用，但也可能导致网络问题出现。
经过校验，发现TS服务器每次出现卡顿的时间点恰巧与混杂模式进出时间一致，判定是混杂模式的进出导致的语音服务器网络波动。
2024/2/13补充：
新发现TS语音出现另一类错误，偶尔会出现长达5~10秒的语音”空白(无声)”，此次系统日志中错误代码如下。可以推论出TS语音卡顿在服务器端通常与kernel(内核)相关，本次新错误的原因与解决方法详见：宝塔面板登录引发报错：kernel python3 error:0 in libstdc++.so.6.0.19 - 雾里 (woolio.cn)
Feb 13 00:05:22 [localhost] kernel: traps: python3[29830] general protection ip:7fabe1c1aa3f sp:7fff9001d770 error:0 in libstdc++.so.6.0.19[7fabe1b5c000+e9000
修复
经过调查，发现BT-Task进程下的libpcap.so有嫌疑，于是将相关文件一并移至回收站（可能有误杀请谨慎），文件如下：
/usr/lib64/libpcap.so.1.5.3
/www/server/panel/pyenv/lib/python3.7/site-packages/pcap.cpython-37m-x86_64-linux-gnu.so
/www/server/panel/pyenv/lib/python3.7/site-packages/pypcap-1.3.0.dist-info移至回收站后重启服务器，经过一段时间测试后发现系统日志中不再有网卡进入混杂模式相关记录，同时语音问题也解决。