gpt4 book ai didi

录音虚拟驱动杂音bug修复

转载 作者:撒哈拉 更新时间:2024-12-15 16:47:52 57 4
gpt4 key购买 nike

永远选择相信同步原语 。

起因

qemu有一个可以让虚拟机(guest)使用宿主机(host)的音频播放的参数,-device audio。这个参数在x86上效果不错,但是在arm上效果不行,杂音很多,所以我们需要解决这个问题。方案是使用共享内存ivshmem.

具体的说,就是改写微软的官方样例驱动。虽然这些bug看起来简单,但是由于windows的奇怪特性,以及ARM上没有合适的调试工具,所以我们调试了很久很久…… 。

调试的故事

调试的方法无非是打日志、看coredump、单步调试.

  1. 打日志

打日志可以用DbgPrint,它的输出可以用过DbgView看到.

DbgView有ARM架构版本的,也有x86版本的。虽然微软确实有x86转ARM指令集的功能,但是DbgView ARM版本异常容易崩溃,只能够用一小段时间,然后就会崩溃……据说qemu有串口输出日志的功能,但是由于我们要使用内核态,所以这个功能难以试出来.

  1. 看coredump

这个功能在x86上是可用的,在ARM上因为一些奇奇怪怪的问题,我们要用BcdEdit开启。大致只记得开启了测试模式,然后对照x86去修改其他bcd选项,然后又开了其他几个选项,不限制coredump大小,此时才有概率能够产生coredump。好在崩溃问题几乎是必现的,所以最终能够在几次重启之后正常获得coredump.

  1. 单步调试

据同事说,他曾在x86上用过这个功能对内核态驱动实体机单步调试,但是我们试过很多方法,花了大约两三天,都没有搞定.

最终结论,具体说,要使用单步调试,我们就需要网络,在进入系统前就必须要有网络。但是!我们只能在虚拟机中调试,而虚拟机中的驱动是在系统启动之后才加载,所以我们用不了这种方法.

当然,微软还提供了几个选择,比如可以用串口来单步调试,但是估计串口驱动也可能是在启动之后加载的,再加上在调试过程中我已经找到了崩溃的原因,所以就没有继续研究了.

所以,微软,我xxx 。

BUG1:缺乏同步原语导致的杂音

这是在录音这一部分遇到的bug。这里说的杂音是说,如果你给他录制人声,你能够听得出是这个人说的话,但是你听不清他说的是什么内容。如下图 。

image

也就是说,在真正写入数据之前就已经开始录音了,表现的效果就是听不清在说啥.

而播放是没有这个杂音问题的,也需要画图说明.

image

也就是说,播放的时候,在本次数据完整交给host播放之前,下一次数据是阻塞等待的.

所以录音有杂音,而播放无杂音,本质上就是同步原语的问题。我们无法修改windows内核的代码,所以没法用类似于播放的方法.

至于为什么非得要一个IO线程,就得看气人的安全措施protection ring:

image

https://en.wikipedia.org/wiki/Protection_ring 。

这个ring中,ring2级别的无法访问ring0、1级别的内容。而我们的驱动运行在两个级别中,初始化的时候是0,初始化之后,读取、写入音频数据的时候是2,而在IO线程中是0,而IVSHMEM共享内存的ring级别就是0.

所以摆在我们面前的只有两个方案:

  1. 在IO队列与驱动之间加一个缓冲区

IO队列将所有能够读到的数据放入缓冲区,然后在windows请求读取的时候,之间从该缓冲区中读取。这样就可以解决这个问题了.

这个方案有几个问题。初始化的时候获取的ring级别是0吗?加入缓冲区导致的延迟可以接受吗?

  1. 让IVSHMEM可以在ring2级别中读取,规避掉IO线程

这是我们最终的方案,修改qemu的IVSHMEM源代码,让它能够跑在ring2级别中。具体修改的过程,只记得是IVSHMEM明明已经支持了这个功能,但是它没有开放给用户用,所以稍微加一个if-else就搞定了 。

BUG2:作为同步使用的WorkItem为NULL导致的驱动崩溃

这个bug似乎是和对象构造、析构相关的。它在播放与录音中都出现过,但是特点是:

只在arm上出现,不会在x86上出现 。

不过由于我们最后规避掉了IO线程,所以这个问题只在播放中出现过.

就是因为这个bug,我们花了大把时间在开启coredump上。coredump的问题已经讨论过了。最后修复它的方案就是分割驱动为一个录音驱动和一个播放驱动。虽然确实可以查出来该问题的根本并修复,但是我们发现用简单的方法处理了之后,在ARM上播放依然有杂音。所以我们当时推测是播放录音有相互干扰,所以分割为两个驱动,到此发现杂音没了.

如果时间够的话,我还真想排查出来WorkItem为什么会被释放。我们时间不够了,必须要赶紧做完这东西.

现在回想起来,说不定是ARM的内存屏障没有x86那么严格。我听说有一个公司将x86的java程序放arm上执行的时候就因为这个出现过毛病.

最后此篇关于录音虚拟驱动杂音bug修复的文章就讲到这里了,如果你想了解更多关于录音虚拟驱动杂音bug修复的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

57 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com